Dennis Allison wrote:
The issue here has had to do with session variables and their iteraction
with the persistence mechanism and conflicts and multiple threads for the
same session. Chris McDonough has pointed out that session variables can
cause writes and write conflicts even if the only Zope
The side effect is that sessions will live longer than the specified
period, up to 300 seconds longer if session-resolution-seconds is set to
30 seconds.
In my case, setting it higher helps, b ut does not eliminate the problems.
On Wed, 21 Dec 2005, Maciej Wisniowski wrote:
>
> >The missing d
The missing detail here is that reading a session object causes a
write to the database to update the last access time for that session
object. So what looks like a plain old read to the application code
above, in-fact includes a write just below the surface. (This is a
design choice so that sta
On Dec 21, 2005, at 2:17 PM, Dennis Allison wrote:
I have begun to think that the Zope session variable mechanism, as
implemented, addresses a different part of the storage spectrum
than we
need. A small number of per user parameters (3 to 10) are used by
almost
every request. Most of the p
Michael --
You raise an interesting point. We use sessions to hold the
volatile state for each user in a highly interactive, highly personalized
site. A session lasts from login until logout or until there has been no
activity for a long time. Perhaps, if I were to simply excise the session
ti
On Dec 21, 2005, at 1:07 PM, Dennis Allison wrote:
Sorry if I appeared unresponsive--the fact that we use frames is
hardly a
secret. I suppose that it would be helpful to make up soem
summary of
features for ongoing threads like this one.
It was a secret to me (again, perhaps because of m
On 12/22/05, Dennis Allison <[EMAIL PROTECTED]> wrote:
> The issue here has had to do with session variables and their iteraction
> with the persistence mechanism and conflicts and multiple threads for the
> same session. Chris McDonough has pointed out that session variables can
> cause writes an
On Wed, 21 Dec 2005, Chris McDonough wrote:
> On Dec 21, 2005, at 11:38 AM, Dennis Allison wrote:
>
> >
> > 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
On Dec 21, 2005, at 12:40 PM, Dennis Allison wrote:
Chris W,
The issue here has had to do with session variables and their
iteraction
with the persistence mechanism and conflicts and multiple threads
for the
same session. Chris McDonough has pointed out that session
variables can
cause
Chris W,
The issue here has had to do with session variables and their iteraction
with the persistence mechanism and conflicts and multiple threads for the
same session. Chris McDonough has pointed out that session variables can
cause writes and write conflicts even if the only Zope level access
On Dec 21, 2005, at 11:38 AM, Dennis Allison wrote:
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
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
Chris McDonough schrieb:
..
> 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.
>
Or even drop frames completely. They are too much pain for too less
gain imho.
___
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 l
Dennis Allison wrote:
Ah so desu. That's the conceptual hook I was missing. Only one
transaction per request and no subtransactions!
ZODB substransactions won't help you here in the slightest...
A transaction is
processing initiated by a client request or a redirect. (Anything else?)
A
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.
In the sense I used them below, a transaction and a request are the same
thing. This follows from the fact that each
Write conflicts happen for a transaction. In Zope, there is one
transaction per request.
There are two distinct sections to the navigation_box transaction.
There's a transaction for something named "navigation_box"? Is this
an IFRAME?
One
where the session variables are read and a sec
There are two distinct sections to the navigation_box transaction. One
where the session variables are read and a second where they are used. To
minimize conflicts, the what is now a single tranaction should be split
into two separate transactions.
Any thought as to how to do that? If navig
One more thought ---
On Wed, 21 Dec 2005, Chris McDonough wrote:
> > The structure of the method is simple enough: there is a large
> >
> > block which populates local variables with data from the session
> > variables
> >
> > > ...
> >>
> >
> > with the body of the contai
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 tha
The structure of the method is simple enough: there is a large
block which populates local variables with data from the session
variables
with the body of the containing 300 lines or so of dtml,
control code, sql queries, and occasional dtml-let blocks to hold
query result
Zope 2.8.4
ZODB 3.4.2
I have a dtml method which is an obvious hotspot. It puts up navigation
wigetry and is rendered on nearly every page. The logs show it generates
a large number of conflicts. The conflicts are in TemporaryStrorage and
so are due to session variables.
The session variables
22 matches
Mail list logo
