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: "James K. Lowden" <jklowden AT freetds.org>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] Loss of connections
  • Date: Mon, 18 Dec 2006 11:56:31 -0500

ZIGLIO, Frediano, VF-IT wrote:
> >
> > 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.
> >
> > I don't find anything in the ODBC
> > specification that describes what we do.
> >
>
> Cancel in ODBC means basicly send cancel.

Acknowledged. db-lib and ct-lib have similar functions. But when libtds
sends a cancel packet, it must be subject to the same timeout. I think we
agree on this?

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

My shorthand, sorry to confuse. Let me try again.

tds_goodread() times out on net.c line 406. It calls the
tds->query_timeout_func callback. Already this is broken: control should
go to _dblib_err_handler and never does. The application installed an
error handler with dberrhandle() that is supposed to tell libtds what to
do with *all* errors, including timeouts.

(I know ODBC does not have a client-installable callback. Does the ODBC
library install a default one for libtds to call?)

True, SYBETIME is not a libtds value. We need TDSETIME. It has to be
passed to the client's callback. Because the semantics are different for
each client library, we do this:

timeout ->
tds_client_msg(TDSETIME) ->
tds_ctx->err_handler(TDSETIME) ->
[e.g.] dbperror(SYBETIME)
application callback returns INT_CANCEL
returns TDS_INT_CANCEL
close connection
return FAIL

Cf. dbperror() comments, dblib.c line 7542.

Each library needs its own tds_ctx->err_handler to interpret libtds error
numbers.

ODBC should have the same interface to libtds but a different interface to
the application. It doesn't permit the application to install an error
handler:

timeout ->
tds_client_msg(TDSETIME) ->
returns TDS_INT_TIMOUT (first time)
send cancel packet
timeout ->
tds_client_msg(TDSETIME) ->
returns TDS_INT_CANCEL (cancel packet timed out: give up)
close connection
return FAIL

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

No, IMO we should remove tds_socket->query_timeout_func. We should
instead use tds_client_msg(). (tds_client_msg() needs work, though. It
takes too many parameters. It should take only a msgno.)

> 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

I think it must close the connection and fail the call. Otherwise the
client application hangs.

> So under Windows INT_EXIT behave like INT_CANCEL

Yes. It's db-lib's job to do that, which it does. See dbperror() logic.


(You see, I didn't know we had tds_socket->query_timeout_func, so I wrote
dbperror to handle timeout error per specification.)

Regards,

--jkl




Archive powered by MHonArc 2.6.24.

Top of Page