FreeTDS Development Group

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

Nick Kew wrote:
> (a) threads *can* share a DBPROCESS provided Thread 1 cleans up any
>      cursors (or transactions) before Thread 2 uses it.
>  (b) A process can keep a pool of DBPROCESSes, and threads can use
>      different DBPROCESSes in parallel.
...
> Can someone confirm that my assumptions are (or should be) safe
> and I need to be looking elsewhere for a bug?

There's no relationship between server-side resources -- temporary tables,
transactions, cursors, etc. -- and client-side threads.  The db-lib thread
restriction derives from the fact that db-lib maintains connection state
information at the process level: there is one connection per process, and
that connection's state is kept in the process's DBPROCESS structure.  

In short, db-lib knows nothing of threads.  It doesn't care if one thread
issues the query, another fetches the metadata, and a different thread
fretches each row.  The only contraint is that the threads in aggregate
must treat the DBPROCESS as a process would, making the function calls
serially and in the right order.  

It's very easy to get that wrong and hard to correct.  You may find the
TDSDUMP helpful; there is a way IIRC (or, anyway, could be) to include the
thread id in the log file.  

HTH.  

--jkl