Tim, thank you very much for your careful analysis and explanations.

I should have been more precise wrt the connection between the crash and
our usage of
B-Trees. Indeed, the access viol *is* in the _OOBtree.pyd module, but as
the Python 
process crashes, I have no clue what it was doing at that point (I just
assume must 
we access a B-Tree). 

In the tests I describe, I used the actual application (too big to
include in the margin
of this message) - but the actual code exercised was indeed the stated
loop (but as you
said, there is an additional mapping between the Connection.root() and
the B-Tree).

This said, your analysis was right the point and explains why raising
the ZODB cache 
size makes it (at least) rarer, the buckets presumably having less
chance to be in 
ghost state. 

You are correct that we're accessing one connection with multiple
threads. The reason
is that we have many very long-running calculations which also use a
large portion of
objects in our DBs. The app is most efficient when we use almost all
memory space as
ZODB cache - i.e., ~1.5 GB. If we multiply that per connection, we'd
go into massive trashing or out of address space. 

So I will try (i) to pinpoint the crash more closely (by using a debug
build) and (ii)
try to lock around our accesses (which is difficult, as loading a
ghostified object
is an access as well).

In the longer run, I assume you're suggesting we should look for another
way to access
ZODB, or for another DBMS altogether (not to our liking)?

Thank you again, and best regards,
For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -  ZODB-Dev@zope.org

Reply via email to