FreeTDS Development Group

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

On Thu, 08 Jan 2004, Kent Scott <kscott AT logicalsi.com> wrote:
> I suspect axing the "timeout" member would
> >be a good first step.
...
> The connection timeout (connect_info->connect_timeout) seems to have the
> 
> most implementation in place. There seems to be 3 ways to set its value
> - tds_parse_conf_section(), dbsetlogintime(), and tds_set_timeouts().
> The first of those 3 is obvious - my guess from the other 2 was that
> they were set up to be called either by the programmer in the code or by
> any other language (such as PHP) during an initialization routine? 

tds_set_timeouts() is a self-labelled hack.  IMHO we should write
tds_config() -- based on ct_config() -- to manage connection options, and
get the client libraries out of the business of writing to the data
structures.  But that's not a necessary precondition to making query
timeouts possible.  

dbsetlogintime() is a login timeout, not a query timeout.  If you will,
it's managing a template value: when a new connection is opened, its login
timeout value is taken from that set with dbsetlogintime().  This is a
published db-lib function.  It might be called by PHP, depending on how
PHP was configured.  

tds_parse_conf_section() should IMHO also not write to the structure, but
call my putative tds_config().  

> I did notice that PHP does attempt to call dbsettime() 
> except that it isn't implemented yet. The only part that was throwing me
> 
> off was that tds_parse_conf_section() was looking for and setting
> timeout and not query_timeout. 

Right.  I don't see much point in adding query_timeout to freetds.conf.  I
suppose we could, but why?  The docs all say that the default is no
timeout, so every application has to be written to set the timeout itself
via the API.  

I think it's more important to write dbsettime() and perhaps its libtds
counterpart.  You're using the mssql extension, I take it.  

> Would it make sense then to implement dbsettime() to 
> act like dbsetlogintime() for query_timeout as well as to parse 
> freetds.conf for the value?

If by "act like dbsetlogintime()" you mean, "make dbsettime() do what
Sybase says it should do", yes.  Else I don't understand the question. 
:-)

> I do believe that goodread() needs to be slightly modified for the 
> query_timeout to work. It goes in to a do..while loop if the timeout is
> set and exits if the time passes (this part works fine). However, the
> very next thing it does after exiting the loop is to call READSOCKET()
> where it still hangs. We would need to test if the socket is dead or
> something and return instead.

That's definitely the harder part.  There's a long chain of events that
has to respect the timeout value and react to the timeout.  

> As for error handling - I was hoping to avoid looking in to that -
> although I do need it. I will start trying to get at least a little
> familiar with it. Just give me your thoughts.

It's totally necessary, but you have a shortcut at your disposal.  The
general solution requires rewriting our error handling and discarding
tds_client_msg().  I've written about that at some length before, and
won't repeat myself here, for your sake.  The shortcut, for better or
worse, is to *use* tds_client_msg().  It needs a little modfication, IIRC,
to make sure it passes the error handler's return code back to the caller,
because that's how the handler tells the caller -- goodread(), in this
case -- whether to retry or give up.  

ct-lib and db-lib have different notions of how to react to a timeout, of
whether or not the connection can continue to be used, or is marked dead. 
If you want to just get the db-lib semantics working, that's fine.  I'd be
really enthusiastic if you embrace a more general approach.  

In any case, goodread() has to call the error handler to decide what to do
next.  If you re-read the error handling documentation with a Through the
Looking Glass eye, you'll see by inference what the library has to do.  If
you want to understand it, it's a good idea to look at the ct-lib docs,
too.  

--jkl