Skip to Content.
Sympa Menu

freetds - Re: [freetds] Loss of connections

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] Loss of connections
  • Date: Mon, 18 Dec 2006 11:34:34 +0100

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





Archive powered by MHonArc 2.6.24.

Top of Page