On 4/12/07, Maciej Wisniowski <[EMAIL PROTECTED]> wrote:

Currently I have some problems with our application (Zope2.8.4)
and with Conflict Errors in sessions.
In general if we have few concurrent requests that are running
sometimes for 3-4 minutes (and they're touching session inside)
I get a lot of conflict errors with Inceraser, OOBTree, Length2 etc.
These are errors like:

serial starded with xxx serial currently commited xxxx

Of course I know that it is best to move such long processes to
something external with Async, lovely.Remotetask or built
in Oracle jobs, but so far I have to deal with this state of
our application (as I'm not the author ot this but rather
something like an zope admin/supporter for this app).

I think that ConflictErrors are caused because of sessions
implementation, especially: timeslices, "current" bucket etc.
as written in Transience/HowTransienceWorks.stx.
Changing session_resolution_seconds to big value
helps here. By default we had session_resolution_seconds
set to 300.

You could keep experimenting with values to reduce the chances of
conflicts. Perhaps sessions that last for days. With resolution of
hours. Disabling inband housekeeping.

Note that a session-timeout-minutes of 0 enables a slightly different
approach which has a little less "active" structure.

I wonder how this happens. If I have two requests that at the beginning
modify it's sessions like: session.set('aa', 1), and then call long
running ZSQLMethods then (if meanwhile timeslice has changed because
of too short session_resolution_seconds):

- first request that finishes finds that there is new 'current' bucket
  and moves it's session object and second request's session object to
  new 'current' bucket and commits this

- second request finishes and finds that it's session object is not
  the same as it was at the beginning (because it was moved to 'current'

Anybody can say if I'm right here?

I don't think session mechanics operates like that at the end of a
transaction. More generally what is happening is that the second
transaction is trying to commit data that was changed by an earlier
transaction after second transaction read that data. In this case the
data is various bits of the internals that make up sessions and
transience storage.

Very careful use of explicit transaction commits may be all that you
need in your application. For example, make all your edits of the
session data early in the request and then commit the transaction.
Then proceed with the longer operation. Might be that destroys the
consistency of your application data though.

-- Michael
Zope-Dev maillist  -  Zope-Dev@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 )

Reply via email to