FreeTDS Development Group

["Lowden, James K" <james.k.lowden AT alliancebernstein.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/dblib/@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."

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


-----------------------------------------
The information contained in this transmission may be privileged and
confidential and is intended only for the use of the person(s) named
above. If you are not the intended recipient, or an employee or agent 
responsible
for delivering this message to the intended recipient, any review, 
dissemination,
distribution or duplication of this communication is strictly prohibited. If 
you are
not the intended recipient, please contact the sender immediately by reply 
e-mail
and destroy all copies of the original message. Please note that we do not 
accept
account orders and/or instructions by e-mail, and therefore will not be 
responsible
for carrying out such orders and/or instructions.  If you, as the intended 
recipient
of this message, the purpose of which is to inform and update our clients, 
prospects
and consultants of developments relating to our services and products, would 
not
like to receive further e-mail correspondence from the sender, please "reply" 
to the
sender indicating your wishes.  In the U.S.: 1345 Avenue of the Americas, New 
York,
NY 10105.