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.