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
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
