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 
>That is, each DB connection is serialized to be used by one thread only, but there 
>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 
>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?

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 

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to