[Gfeller, Martin]
> ...
> You are correct that we're accessing one connection with multiple
> threads.
That would appear to explain it then.
> 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
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
I believe I identified one cause for catastrophic thread-race problems here
(sharing a Connection across multiple threads, or for any other reason
sharing an in-memory persistent object across non-serialized threads), even
when objects are never modified. It doesn't look shallow to me.
The C code
Below is a self-contained program that reproduces both symptoms you
described, although I had to use 3 threads to make them frequent. Typical
output:
filling 1 ... 100 200 300 400 500 600 ...
... 9600 9700 9800 9900 1
iteration 0
Exception in thread Thread-3:Traceback (most
[Gfeller Martin]
> We're using ZOPE 2.7.3 with its default Python, ZEO, and ZODB versions
> under Windows 2000 Server SP3. This is a 2xXeon machine, but Python is
> bound to a single CPU.
So that's ZODB 3.2.4. I don't believe any _relevant_ ZODB bugs were fixed
since then (ZODB 3.2.7 will be curr
