FreeTDS Development Group

["James K. Lowden" <jklowden AT freetds.org>]

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.  

> > 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).  

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

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

> - 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.  

> - (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