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 either 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, Martin _______________________________________________ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
