[Zope] resolving conflict errors

[Dennis Allison]

Good idea, but it is hard to do in a production environment with a "never
lose data" model.  I have suspected the p_resolve_conflict which is
clearly wrong for our model and am in the process of trying to rewrite it
to take advantage of the semantics of sessions as we use them.

The problem I am tracking manifests itself as KeyErrors in the session 
data structure.  The session structure is used pretty much out of the box.
Reading is done any which way (e.g,  REQUEST['SESSION'][key]) but writing 
always uses a copy out of the session object, an update of the session 
object, and the a replacement of the session object back into REQUEST.

The session data we lose are generally strings, for example, a user_id.
For example, we can set the user_id into the session to a value, and then 
later, when we reference the session variable, we get a KeyError.  While
there is no direct causal tie, we suspect this is related to an 
intervening conflict error.   

Occasionally the entire SESSION data container disappears.  At other
times, we get a KeyError exceptions for one or more session variables.

I have been trying to understand in detail the management of the session
variables.  I can see how accesses are managed in ZPublisher/HTTPRequest,
but I am still unsure of how that session data is maintained persistent
and how session data can generate read-read conflicts.  

I'll try your suggestion.  I also plan to monitor session variable access 
to determine whether the SESSION data whether a KeyError signals that all 
session variables are missing or whether only a few are missing.


On Sun, 11 Dec 2005, Michael Dunstan wrote:

> On 12/9/05, Dennis Allison <allison at shasta.stanford.edu> wrote:
> > The problem I am trying to resolve appears to be load related.  The
> > observed symptom is that (some) session variables spontaneously disappear.
> > There appears to be some connection to conflicts, but the exact mechanism
> > and the relationship is not yet clear.
> 
> A small possibility is that you are being bitten by the DWIM'ly nature
> of TransientObjects conflict resolution where the last modified state
> is chosen over the others. If you think this is biting you then try
> commenting out _p_resolveConflict of TransientObject. That's bound to
> increase the rate of conflict errors but should provide you with a
> consistent session state. Perhaps useful as a debugging step.
> 
> michael
> 

--