On 12/16/05, Dennis Allison <[EMAIL PROTECTED]> wrote:
> MAYBE CONFLICTS AND THEIR RESOLUTION ARE NOT THE ROOT CAUSE OF THE SESSION
> VARIABLE PROBLEM. The observed problem is that session variables suddenly
Perhaps your app is tripping over some bug in conflict handling. But
I'd say it is worth entertain other ideas too. For now, just comment
out all of TransientObject._p_resolveConflict and if you still get
errors then you know you have to look elsewhere.
(Sure, some of that elsewhere may well include the conflict resolution
code above _p_resolveConflict.)
Your application and sessions should cope just fine in the face of any
ConflictError. ConflictError's are an essential part of the machinery
that keeps data state consistent.
As Chris mentions, look at how your using sessions and some of the
assumptions you might be making. Might be useful to try with sessions
that don't timeout, set session-timeout-minutes to 0. And try
maximum-number-of-session-objects of 0. Also trying the turning those
knobs the other way, session-timeout-minutes of 1 and
maximum-number-of-session-objects of 2.
For now, stay focused on making sure you maintain a consistent state.
Only once you have a consistent state then is it worth trying to
improve the rate of ConflictErrors. (Which in your case of sessions
lasting for many hours I think the numbers you quote elsewhere are too
small. And, yeah, an alternative implementation for _p_resolveConflict
might help there. Personally I prefer the simple approach of just
commenting that out completely and living with a slightly higher
Might be worth trying without ZEO in the mix.
Definitely worth the effort, if you have not already, to recreate the
whole system on a separate host that you can feel comfortable making
changes to. Then you can happily tune the various knobs downwards
which may help with trying to observe the problem. For example
session-timeout-minutes of 1.
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org