[Zope-dev] DA connection pooling thoughts

Matthew T. Kromer matt@zope.com
Wed, 12 Dec 2001 10:30:53 -0500


Brad Clements wrote:

>Sorry if this is FAQ..
>
>I've been reading the petrilli's DA how-to, and thinking about Thunked_TM.
>
>For Interbase, I'm thinking of trying a DB connection pool that threads can "checkout".
>
>That is, each DB connection is serialized to be used by one thread only, but there can 
>be multiple DB connections in a Zope process. We'd maintain a pool of connections 
>from 1 to n.. and each thread making a DA request checks out a DB connection from 
>the pool (if available) and uses it..
>
>I'm trying to figure out of Zope already does this, that is, has one DB connection per 
>thread if I took out Thunked_TM from the DB itself.
>

Sortof.  Basically, yes.

Generally, the DA is going to get a connection object when it is opened. 
 Since each working thread in Zope will get its own PRIVATE copy of the 
DA object, each working thread will have its own connection to the 
database.  It is theoretically possible to share DA connections between 
threads (on purpose, or by accident) but you have to work at it and 
write some Python glue to make it happen.

However, if the underlying adapter is not reentrant, removing Thunked_TM 
will cause the adapter to be reentered for sure, which will probably 
crash the adapter.

>
>Or is it that there are multiple DA's, and the DA uses on internal DB for all the DA's ?
>
>If Zope will re-entrantly call a DA and it's corresponding DB without Thunked_TM in-
>place, then having a connection pool (up to one for each thread) might be worthwhile.. I 
>remember seeing something on the list about per-thread state information being 
>available somewhere.. an oid jar or something?
>
>Anyone have pointers?
>
>Thanks
>

Most of the time when Thunked_TM is used, the underlying adapter can 
only have one operation in flight at any given time; ie it is not thread 
safe.