FreeTDS Development Group

["James K. Lowden" <jklowden AT freetds.org>]

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