Chris, thanks again. You've clarified several issues. Interlinear
comments below, original text edited with a heavy hand for brevity...
On Wed, 21 Dec 2005, Chris McDonough wrote:
> If this is the same getSessionVariable as you reported before (a
> Python Script), note that each call that you make to it has
> overhead. It might be better to create a single Python script to
> return all of the values that you need from the session rather than
> calling this over and over again. If that doesn't work, it might be
> even better to just do SESSION.get('foobar') instead of calling a
> Python Script for every value.
Good point. No overhead is probably the right thing especially since
there are no subtransactions.
> > I still don't have an intuitve understanding of the conflict
> > mechanism in
> > practice. For example, Why is the conflict error reported for the
> > navigation dtml method rather than for the getSessionVariable python
> > script which actually references the SESSION object where the conflict
> > occurs?
> Write conflicts happen for a transaction. In Zope, there is one
> transaction per request. So it reports the URL of the method that
> was called as the thing that caused the conflict (because, basically,
> it was). A conflict is not "noticed" until a transaction is
> committed; ZODB has no idea what caused the data structure to change
> in a conflicting way within "application code".
Ah so desu. That's the conceptual hook I was missing. Only one
transaction per request and no subtransactions! A transaction is
processing initiated by a client request or a redirect. (Anything else?)
A transaction has its own REQUEST and RESPONSE objects.
> > A conflict error gets raised whenever another thread references the
> > same session's SESSION object.
> Are you using frames by any chance? It would be understandable that
> you're seeing an increased number conflicts if you have an
> application in which many threads try to access the same session
> object at once due to a browser making multiple writes to the same
> session object because of frames.
Yes, we do use frames. We manage rendering explicitly with a bit of
certainly could be a contributing factor.
> > Apparently the MVCC read-read conflict
> > resolution fails for session variables although I am not sure why.
> Can we see one of the conflict tracebacks? You should be seeing only
> write conflicts. Read conflict errors are reported in a traceback
> with a ReadConflictError message (conflicts reported as only
> ConflictError are write conflicts).
I'll try to find a few tracebacks.
Zope maillist - Zope@zope.org
** No cross posts or HTML encoding! **
(Related lists -