[Zope] More on understanding conflicts

[Chris McDonough]

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