I'm pretty confident that the db component (the C layer) doesn't have any GIL problems. However, the DA component (the Zope layer) *may* have all sorts of unusual failure modes.

Debugging transaction concurrency problems is always tricky, but keep in mind there are Python layer abstractions that get and release locks as well.

I'm speculating based on the history of your discussion thread that you're running out of Zope db connections. The way it works in Zope is somewhat unusual; there are usually NOT enough object database connections if you run more than four threads (unless someone fixed this way back when, the default was 7). Threads in Zope wait in line for a zodb connection to become available. Under normal circumstances they don't have to wait, but in yours I think they are waiting. Are you trying to run with more than four threads? If so you might want to tweak the pool_size parameter up in the DB class of lib/python/ZODB/DB.py. There are negative consequences of doing this (ie each DB connection cache gobbles memory) but on the upside you might be able to avoid stalling out Zope.

This won't provide you relief the way you might hope; if the problem is that threads are entering a long running transaction and waiting on Oracle to complete, all you're doing is adding a few more feet to the rope before Zope hangs itself up again.

DCOracle2 does support event tracing, so you could turn on the trace log to see what the module is doing when Zope is becoming nonresponsive. It probably will say that it's waiting in a fetch or execute statement, so that won't be all too terribly helpful but it MIGHT indicate that there's a problem with handles (some versions of DCOracle2 leaked a handle -- make sure you have the latest code from the CVS repository).

Also, the C layer isn't capable of coping with some result types very well (if at all) ie using Oracle in object mode or returning table results from stored procedures, etc.

Also, the PYTHON layer code that currently exists as the DA *does* leak connections if Oracle closes the connection. This is something Chris Withers tried to fix, but I think he was never happy with the solution and so it remains on a branch.

I haven't done any DCO2 development in a little over two years; I hate to abandon the code but I don't run any current Oracles at home and its a fairly intensive time commitment to just set up a development environment. Oracle never gave me any freebies either, / sniff -- not that I expected any mind you, but the best way to stay current with them costs $$ that I'm not likely to fork over any time soon.

On May 3, 2006, at 3:36 PM, Michael Mauws wrote:

Thanks yet again, Dieter, particularly for putting to rest a few of
the "solutions" I found while poking around. As you might expect, I've
been continuing to explore this problem and, at the moment, I'm
zeroing in on rollback segments. If this is indeed the problem, it
would fit well with what you're saying....


Zope-DB mailing list

Reply via email to