[Zope-dev] Question about _v_ attributes and database connections

[Kapil Thangavelu]

fwiw, i think this is a viable solution (although you should not only
scope connections to thread local but to da paths in the module level
global) as there are problems with zope and das going away because of
their volatiles.. it can lead to strange behavior, like say your in the
midst of a long txn, the da conn is involved gets registered w/ the txn.
during the course of the txn the da persistent object is ghosted, latter
it comes back but it will do so with a different connection if used
again, this is bad from an rdb txn isolation pov, because assuming any
isolation it can't see the changes done with the other as yet
uncommitted connection (still alive cause its ref indirectly from the
zope txn itself).
 
unfortunately this is arch. problem with zope and current rdb/da
integration and the only real solution that i see is via module level
global storage for conns.

as for shutdown of these conns, easiest might be to register an atexit
function, or a cleaner sweeper thread with last usage times and in txn
status on the otherwise thread local conn storage.

cheers,

-kapil
 
On Thu, 2004-03-11 at 06:56, Marco Bizzarri wrote:
> On Thu, Mar 11, 2004 at 11:49:34AM +0000, Chris Withers wrote:
> > Marco Bizzarri wrote:
> > 
> > > I'm trying something inspired to that at the moment... I succeeded in
> > > installing an hack, very inspired from your code (but at a much simpler
> > > level) and some code in the SecurityManager,
> > 
> > ?!
> 
> Look in AccessControl/SecurityManagement.py, the getSecurityManager()...
> it does in that way.
> 
> > > where I mantain a dictionary
> > > of connections, indexed by the result of thread.get_ident(). 
> > 
> > :-(
> 
> I know, it is an hack :(
> 
> > > Once a
> > > thread needs a new connection, either it is present in the dictionary
> > > or not. If it is present, give it to the thread and assign that to the
> > > _v_database_connection attribute. Otherwise, create a new one, put in
> > > the dictionary, and go on as before.
> > 
> > When do these connections get closed?
> 
> Never, for the moment.
>