FreeTDS Development Group

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

Frediano Ziglio wrote:
> > We do not yet have a reliable way to do this, because each client
> > library has its own convention for handling timeouts.  Db-lib and
> > ct-lib expect different error codes and return different values (and
> > have different semantics).  Meanwhile, libtds does  not know which
> > client library established the connection, and thus cannot know what
> > semantics to use.  The solution to *that* is to create a consistent
> > interface to libtds, and let it call out to the client library, which
> > will in turn invoke the handler and return a consistent error code to
> > libtds.  Obviously, a first step would be to modify TDSSOCKET to
> > record the client library in use.  
> 
> Whatever library all libTDS has to know is how to behave in timeout
> situations... this should be possible using current timeout callback.
> IMO what should be revised and tested should be dblib/ctlib behavior
> (dblib particularly).

Agreed.  Keep in mind that the application's handler will be different,
depending on whether it's db-lib or ct-lib.  The rules are different, even
though at the tds layer it all boils down to retry/abort.  That's why each
library needs its own intermediary to interpret the handler's return code
and convert it into libtds's single form.  To do that, libtds has to know
which intermediary to call.  

application
    API library
        libtds
            goodread (or whatever)
                error
                determine API
                    API intermediary
                        application's error handler
                    convert API return code to libtds code
                retry or abort

I hope that's clear.  Tell me if not.  

Regards, 

--jkl