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 <[EMAIL PROTECTED]> 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 > -- _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )