FreeTDS Development Group

["ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>]

> 
> ZIGLIO, Frediano, VF-IT wrote:
> > > 
> > > > From: ZIGLIO, Frediano, VF-IT
> > > > Sent: Thursday, December 07, 2006 3:54 AM
> > > > > 
> > > > > What src/tds/net.c::tds_goodread() should do on receipt of
> > > > > INT_CANCEL from the error handler:
> > > > > 
> > > > > 1.  Close the socket.  2.  Mark the connection DEAD.  
> 3.  Return
> > > > > failure.
> ...
> > > When a db-lib error handler returns INT_CANCEL, it means 
> the called
> > > function should fail.  Both Sybase and Microsoft say when 
> > > INT_CANCEL is
> > > returned for SYBETIME, the connection will be broken:
> > 
> > Oppps... I applied only ODBC specification...
> 
> Why do you think so?  I don't find anything in the ODBC 
> specification that
> describe what we do.  
> 

Cancel in ODBC means basicly send cancel.

> > > I like Sybase's specification better, because it places 
> control in the
> > > hands of the error handler.  For SYBETIME:  
> > > 
> > > 1.  To retry, return INT_CONTINUE.
> > > 2.  To (try to) cancel, maintaining the connection, return 
> > > INT_TIMEOUT.
> > > 3.  To break the connection, fail the function, and 
> return control to
> > > the application, return INT_CANCEL.  
> > >
> > > > The problem is that tcp
> > > > stack cannot safely detect some network problem.... 
> > > 
> > > Exactly.  Application programmers don't want to be at the mercy of
> > > tcp/ip timeouts.  
> ...
> > > I think ODBC should behave the same way.  I know there's 
> no callback.
> > > The built-in error handler should retry once and then fail.  
> > > IOW, return
> > > INT_TIMEOUT, followed by INT_CANCEL if called a second time.  
> > 
> > Mmmm... I'm thinking something very easy libTDS implementation...
> > In tds_goodread call callback and
> > - if connection was closed return else reset timeout 
> (start_ms = now_ms)
> > and just continue...
> > Or perhaps let callback return newer start_ms.
> 
> libtds communicates with the callback by sending an error code (e.g.
> SYBETIME) and receiving a return (e.g. INT_CANCEL).  
> 

SYBETIME have nothing to do with libTDS...

$ cgrep SYBETIME
./include/sybdb.h:#define SYBETIME        20003 /* SQL Server connection
timed out. */
./src/dblib/error_table.h:{        SYBETIME,          EXTIME,   "SQL
Server connection timed out."},
./src/dblib/dblib.c:    , { SYBETIME,              EXTIME,
"Adaptive Server connection timed out" }
./src/dblib/dblib.c: *  value for anything but SYBETIME, it's treated
here as INT_EXIT (see above).
./src/dblib/dblib.c:    if (msgno != SYBETIME) {
./src/dblib/dbutil.c:    * for non-SYBETIME errors in the strange and
different ways as
./src/dblib/dbutil.c:   if (msg->msgno != SYBETIME) {

with "callback" here I refer to tds->query_timeout_func, in tds.h

        /* timeout stuff from Jeff */
        TDS_INT query_timeout;
        int (*query_timeout_func) (void *param, unsigned int
total_timeout);
        void *query_timeout_param;
        unsigned int query_start_time_ms;

Mmm... well perhaps dberrhandle callback should be called by
dblib_query_timeout...


> I believe the behavior of all three libraries can be 
> implemented his way. 
> I believe ODBC's behavior should be much closer to the 
> default handler for
> db-lib.  
> 
> > - if exit just call exit
> 

In ODBC there is no callbacks, you set a timeout and library
automatically cancel query. I don't know however if ODBC close
connection automatically when server do not send anything after cancel
...

> Yes.  Except if msdblib-compat, then return FAIL.  (MS db-lib 
> never calls
> exit(3)). 
> 

Isn't INT_EXIT supported by MS db-lib ? Perhaps reply is at 

http://msdn2.microsoft.com/en-us/library/aa937031(SQL.80).aspx
(you send this link)

"Prints an error message and exits the application. DB-Library also
returns an error to the operating system. With the Microsoft(r)
Windows(r) operating system, this value is considered an error and is
treated as an INT_CANCEL."

So under Windows INT_EXIT behave like INT_CANCEL

> > - if cancel call tds_send_cancel (which shouldn't reset timeout!) 
> 
> Right!  On SYBETIME, callback returns INT_TIMEOUT to cancel, 
> INT_CONTINUE
> to retry, and INT_CANCEL to break the connection and fail.  
> 
> > optionally set new timeout (on second call callback can 
> check in_cancel)
> 
> Not sure I understand.  
> 

I think we are looking at two different places, I'm focused on
tds_goodread while you are focused on dberrhandle.

> > - (added) if we want to close connection close, 
> tds_goodread will detect
> > this
> > (the subject here is the callback, so no code in libTDS)
> 
> The callback decides whether to retry, or attempt to cancel, or fail. 
> (A)bort, R)etry, or I)gnore?)  libtds just tells the callback what the
> situation is, and does what the callback tells it to do.  
> 
> AFAIK it is OK for the callback to return INT_TIMEOUT, then 
> libtds issues
> a cancel to the server, times out, calls the handler again 
> with SYBEIME. 
> The callback knows the second SYBETIME refers to the cancel.  
> It can ask
> for the cancel to be retried with INT_TIMEOUT or give up with 
> INT_CANCEL. 
> 
> 
> IOW, it's up to the handler to maintain state, to know whether this
> SYBETIME refers to the original query or the cancel attempt.  
> The library
> just keeps sending SYBETIME until either it succeeds or the 
> callback tells
> it to give up.  
> 
> Regards, 
> 
> --jkl

bye
  freddy77