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

Zope maillist  -  Zope@zope.org
**   No cross posts or HTML encoding!  **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )

Reply via email to