[Zope] More on understanding conflicts

[Dennis Allison]

Chris, 

You asked about frames a while back and I responded in the affirmative.  
I am sure I mentioned that we use frames and framesets and explained that
we use a bit of Javascript to manage loading individual frames rather than
loading the entire frameset whenever possible.  Still, your point about
the multiple threads due to the requests from individual frames when a
frameset gets rendered is a valid one and one I have not given the weight
it deserves.

Issues around multiple threads and concurrency is going to be more and
more of a problem as we move to smarter clients and AJAX-like
implementations.

It looks like there are several small things I can do to improve the 
present system's conflict rate, but, absent some major structural changes,  
I won't be able to drive them to O(zero).  Fortunately, while the level of 
conflicts is high, they are infrequent relative to the number of hits
served, and most are resolved by the normal Zope conflict resolution 
mechanism.


On Wed, 21 Dec 2005, Chris McDonough wrote:

> On Dec 21, 2005, at 10:32 AM, Dennis Allison wrote:
> > Thanks again Chris for the helpful comments.
> >
> > The navigation_box, in this context is just a table which is rendered
> > into a frame in our standard frameset.  It is not an iframe.
> 
> So you do use frames!  That's a huge clue.  I wish I didn't feel like  
> I had to drag that out of you. :-(
> 
> > In the sense I used them below, a transaction and a request are the  
> > same
> > thing.  This follows from the fact that each request is managed as a
> > single transaction.  Perhaps it would have been a better choice of  
> > words
> > to use "request".
> >
> > I suggested breaking the request into two requests as one way to help
> > manage conflicts.  Only the first part of the the split request would
> > reference the session variables, so the window of opportunity for a
> > session variable conflict would be smaller even though the number of
> > requests is larger.
> 
> This is probably not really a reasonable thing to do.  A request is  
> generated by a user agent.  With a lot of deep dark magic, you *can*  
> generate a request from within Zope that makes it appear that it  
> comes from the outside, but it's not easy and unhelpful here.   
> Remember what I said about the "write on read" pattern of sessions?   
> it doesn't matter if you're "only reading" session data.  There still  
> may be writes happening.   Breaking things up into more requests will  
> not help.
> 
> What you want to do instead is *not access the same session from two  
> different requests at the same time*.  You probably know this, but  
> when a frameset is used, the browser generates N requests... one per  
> frame.  These requests happen at about "the same time" whenever the  
> frameset is accessed by a user.  Moreover, since the requests come  
> from the same browser, the session identifier for both requests is  
> the same.
> 
> By accessing session data from code within more than one frame, you  
> are essentially creating a situation where at least two different  
> threads will always be accessing the very same session object  
> whenever the frameset is rendered.  For as many frames as are in the  
> frameset, if the code that renders each frame access the session, a  
> transaction will touch the same session data object and perhaps some  
> shared housekeeping data structures.  It's as if you're pressing the  
> "refresh" button in rapid succession on a page that accesses session  
> data.  This is prime area for a conflict.
> 
> > And, sigh, you are probably right--it may be time to abandon the  
> > standard
> > release session implementation and roll our own.
> 
> This is still a reasonable thing to do, but if you can get away with  
> using sessions in only *one* of the pages of your frameset, things  
> will get much better.
> 
> - C
> 

--