[Zope-dev] Sessions and long requests = conflicts? Mcdutils?

[Michael Dunstan]

On 4/12/07, Maciej Wisniowski <maciej.wisniowski at coig.katowice.pl> wrote:
> Hi
>
> 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'
>   bucket)??
>
>
> 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