Skip to Content.
Sympa Menu

freetds - Re: [freetds] Fw: FreeTDS vs Threads

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "James K. Lowden" <jklowden AT freetds.org>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] Fw: FreeTDS vs Threads
  • Date: Fri, 29 Jun 2007 10:45:45 -0400

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




Archive powered by MHonArc 2.6.24.

Top of Page