On 4/12/07, Maciej Wisniowski <maciej.wisniowski@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