[Zope] Versioned connectors from ZODB

[Etienne Labuschagne]

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