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....
On 5/3/06, Dieter Maurer <[EMAIL PROTECTED]> wrote:
Please always stay on the list!
Michael Mauws wrote at 2006-5-2 14:39 -0600:
>In light of the above, I don't think it's a GIL problem (without
>having a clue what a GIL actually is)
This is the "Global Interpreter Lock". It prevents more than
a single thread to run Python code at the same time.
If C code does not access Python data, it may release the GIL
(and than run in parallel with Python code). If it forgets
to release the GIL, then no Python code can run.
>or a DCOracle2 problem. Instead,
>I think it may be related to Zope's transaction algorithm
This is quite unlikely.
While Zope cannot concurrently commit more than a single
transaction (committing is synchronized on a per storage
level) it can run multiple
requests while some requests wait on database locks.
However, should Oracle delay a commit (due to lock contention),
than Zope may not be able to perform further commits.
Note, that this would only affect requests that either modify
the ZODB or an external database.
>I'm not sure how threading works in ZOpe, but it
>appears that my Zope is dealing with page requests sequentially rather
>than in parallel.
That is unusual...
>As I indicated before, some have suggested that this
>is solved with ZEO.
>As well, I found one post that seemed to be
>suggesting the problem had to do with running Zope behind Apache.
It, too, errs.
>either of these explanations make any sense?
Zope-DB mailing list