[Zope] More on understanding conflicts

[Dennis Allison]

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 
Javascript magic so the full frameset rarely gets rerendered.  But, it 
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.

--