Tim, > > . . . Versions solves this for > > me. > > Maybe like death would solve my problem with overdue taxes <wink>.
I did get the versioned connections to work (so far), BUT, I will definately take your word on it and seek another solution :) > <snip> Like, e.g., in the ZODB 3.2 line, > > otherdb = ZODB.DB(storage, cache_size=100, pool_size=2) > > Then connections obtained via otherdb.open() will hang if two threads > already have connections from `otherdb` (that's the effect of > `pool_size`), and will have ZODB memory caches that strive to keep no > more than 100 objects in memory across transaction boundaries (the > effect of `cache_size`). > <snip> to double check: otherdb = ZODB.DB(existingdb._storage, cache_size=100, pool_size=2) is ok? It seems that you can create more than one DB instance that shares one storage object. I hit upon the idea of creating another DB instance and sharing the storage object myself yesterday, but wasn't sure what the repurcussions will be. Your post answers most of my questions. I have one left, though: if I do decide to share the storage object (and not go ZEO for whatever reason), will the caches between the two DB objects not get out of sync? In other words, will one DB object know to invalidate objects in it's caches should that object be changed through another DB instance? I know ZEO does this for you, but I'd like to know what the case would be for two DBs in one process. My other option is to create the connections "by hand" (that way I can control the cache size easily) and keep my own little pool of connections with a modified close method that does not put my connections back into the "normal" pool. But I'm afraid I may end up with a new can of worms that way. > This answer assumes you're using ZODB directly. I don't know details > of how to spell it from within a Zope application (if that's what you > need -- unsure). I use the ZODB directly, but from within Zope. The connections are used in long-running processes that are not nescesarily browser-triggered. Some of them are scheduled events that are started up in their own thread. From there the need to get new connections to the ZODB. I have quite a bit of experience working safely with multiple threads and the ZODB, so I'm sure I have that part right. My problem had more to do with "cache contamination" and reserving "special connections" for specific processes. Thanks for the reply Etienne _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
