[Zope-DB] Zope, DCOracle2, concurrent transactions, etc.

[Michael Mauws]

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....


...michael


On 5/3/06, Dieter Maurer <dieter at handshake.de> 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.
>
> They err.
>
> >As well, I found one post that seemed to be
> >suggesting the problem had to do with running Zope behind Apache.
>
> It, too, errs.
>
> >Do
> >either of these explanations make any sense?
>
> No.
>
> --
> Dieter
>