FreeTDS Development Group

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

> 
> > 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.
> > 
> > IMO this is not the purpose of INT_CANCEL. INT_CANCEL is meant to
> > cancel query, not to close connection. 
> 
> Hi Freddy, 
> 
> Respectfully, no.  You are under a misconception.  :-)
> 
> 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:
> 
> http://manuals.sybase.com/onlinebooks/group-cnarc/cng1110e/dbl
> ib/@Generi
> c__BookTextView/16564;pt=16564;uf=0
>       "Returning INT_CANCEL on timeout errors will kill the dbproc."
> 
> 
> http://msdn2.microsoft.com/en-us/library/aa937031(SQL.80).aspx
>       "INT_CANCEL     Returns FAIL from the DB-Library function that
> caused the error.  For time-out errors (SQLETIME) only, 
> DB-Library calls
> dbcancel in an attempt to cancel the current command batch 
> and flush any
> pending results. If this dbcancel attempt also times out, the 
> connection
> is broken."
> 

Oppps... I applied only ODBC specification...

> 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.  
> 
> If no error handler is installed, the default one is in force.  It:
> 
> 1.  aborts the program if the error has made the DBPROCESS "unusable".
> IOW, the connection is broken, socket closed, because the TDS stream
> became desynchronized.  
> 2.  Otherwise, returns INT_CANCEL.  (For non-timeout errors, 
> INT_CANCEL
> means only that the function fails; the connection is OK.)
> 
> > 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.  The network will try to be a hero to get the packets
> across, which is what it should do until the user loses patience.  The
> query_timeout, when implemented as above, gives the 
> application a chance
> to ask the user, "do you still want to wait?"  The user can say No and
> abort the operation without killing the whole application.  
> 
> If the application couldn't regain control via the error handler, it
> would have to use threads or fork or signals or something.  All those
> are much harder, which I think is why Sybase made it a feature of the
> library.  
> 
> ct-lib supports a similar idea.  ct-lib will not send the 
> cancel packet
> itself, but it allows the error handler to do so, subject to the same
> timeout.  
> 
> http://manuals.sybase.com/onlinebooks/group-cn/cng1251e/ctref/
> @Generic__
> BookTextView/2510
>       "If the callback was invoked due to a timeout error, returning
> CS_SUCCEED causes Client-Library to wait for the duration of a full
> timeout period before calling the client message callback again. It
> continues this behavior until either the command succeeds 
> without timing
> out or until the server cancels the current command in response to a
> ct_cancel(CS_CANCEL_ATTN) call from the client message callback."
> 
> 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.  
> 
> Best regards, 
> 
> --jkl
> 

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.

I think now you raise a question... where do exit, cancel and continue
go? Simply:
- if exit just call exit
- if cancel call tds_send_cancel (which shouldn't reset timeout!) and
optionally set new timeout (on second call callback can check in_cancel)
- on continue just return
- (added) if we want to close connection close, tds_goodread will detect
this
(the subject here is the callback, so no code in libTDS)

freddy77