FreeTDS Development Group

["Brian Bruns" <camber AT ais.org>]

> > TDSCONTEXT holds locale information and a connection list 
> > (replacing the
> > previously global connection list variable).  I truely think this
> > container is the place to store API-wide attributes.  My 
> > concern is that
> > ctlib and ODBC allow for multiple contexts.  It's actually 
> > very rare for
> > an application to use multiple contexts but it would be the case in an
> > apache/perl/php/etc... configuration.  If the API wants to 
> > play games in
> > changing the message handling function it's still free to do 
> > that without
> > chasing down every socket and login structure.
> > 
> > Now, the problem with this scheme.  It was my intention to add the
> > TDSCONTEXT field to CS_CONTEXT and remove TDSLOCINFO from 
> > there.  Also in
> > ODBC we'd need to add it to _henv and remove loc from that as well.
> > 
> > tds_process_msg() needs to be able to look up the handlers 
> > (and probably
> > eventually locales) so a pointer to the active context should 
> > be stored in
> > TDSSOCKET.
> > 
> > This was the direction the code was going, but if you want to 
> > remove the
> > globals, feel free to do the heavy lifting. ;-)
> > 
> > Brian
> > 
> So... 
> TDSCONFIGINFO store information from configuration file
> TDSLOGIN store information for login process and some login configuration
> (such as query timeout)
> TDSSOCKET store information for connection
> TDSCONTEXT should contain information for every API type 
> 
> TDSSOCKET should have a reference to TDSCONTEXT
> 
> Perhaps a method to achive this is add a TDSCONTEXT reference to TDSSOCKET,
> store all needed module info in TDSCONTEXT. Also module can extend
> TDSCONTEXT in a OO-like mode like:
> typedef struct cs_context {
>       TDSCONTEXT tds_context;
>       ... other context info ...
> } CS_CONTEXT;

That works for ctlib and ODBC.  For dblib there is an implicit context
created by dbinit(), so that remains global (one of the warts of dblib). 
We call it an API bug and do our best. There's probably no solving the two
code paths in the same process space both calling dbinit()/dbexit(), just
recommend people move to ctlib if it's an issue.

> Also we must pass TDSCONTEXT to tds_connect (removing TDSLOCINFO)

Indeed, the context is a more appropriate thing to pass to tds_connect()
it will likely grow with our needs in the future (as more stuff is added
to the context it will automatically be available to tds_connect()).
 
> At this point I'd remove connection_list from TDSCONTEXT, add pointer for
> msg/err handler 
> 

Can't remove the connection list.  The be compatible with the API dbexit()
must close all open database connections, so we are required to store the
list of open connections somewhere. cs_ctx_drop() and SQLFreeEnv()
probably should exhibit the same behaviour, but currently don't.  The big
problem here is that the maintenance of the connection list is not
thread-safe, we'd need to control access via a mutex of some sort. I'm
happy to take patches on this one from anybody interested in threading.

> Have I understood ?

Sounds like it.
 
> What about adding a void* pointer to mantain additional data for every
> socket ?

There is void *parent which is really what you probably want.  If per
connection data needs to be stored it's either 1) globally useful in which
case it belongs in TDSSOCKET or 2) API specific in which case it belongs
in DBPROCESS, CS_CONNECTION or HDBC depending on API...aka the parent. For
instance dblib supports two calls dbgetuserdata()/dbsetuserdata() which
does precisely this.

> freddy77

Brian