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 15:30:54 +0100

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

Cancel in ODBC means basicly send cancel.

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

SYBETIME have nothing to do with libTDS...

$ cgrep SYBETIME
./include/sybdb.h:#define SYBETIME 20003 /* SQL Server connection
timed out. */
./src/dblib/error_table.h:{ SYBETIME, EXTIME, "SQL
Server connection timed out."},
./src/dblib/dblib.c: , { SYBETIME, EXTIME,
"Adaptive Server connection timed out" }
./src/dblib/dblib.c: * value for anything but SYBETIME, it's treated
here as INT_EXIT (see above).
./src/dblib/dblib.c: if (msgno != SYBETIME) {
./src/dblib/dbutil.c: * for non-SYBETIME errors in the strange and
different ways as
./src/dblib/dbutil.c: if (msg->msgno != SYBETIME) {

with "callback" here I refer to tds->query_timeout_func, in tds.h

/* timeout stuff from Jeff */
TDS_INT query_timeout;
int (*query_timeout_func) (void *param, unsigned int
total_timeout);
void *query_timeout_param;
unsigned int query_start_time_ms;

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


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

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

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

Isn't INT_EXIT supported by MS db-lib ? Perhaps reply is at

http://msdn2.microsoft.com/en-us/library/aa937031(SQL.80).aspx
(you send this link)

"Prints an error message and exits the application. DB-Library also
returns an error to the operating system. With the Microsoft(r)
Windows(r) operating system, this value is considered an error and is
treated as an INT_CANCEL."

So under Windows INT_EXIT behave like INT_CANCEL

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

I think we are looking at two different places, I'm focused on
tds_goodread while you are focused on dberrhandle.

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

bye
freddy77





Archive powered by MHonArc 2.6.24.

Top of Page