> I have never seen disappearing sessions -- but I must admit > that we use our own session implementation - deriving from > Zope's session but getting rid of the over-complex session > management code.
I've not explained very well. Session object doesn't disappears, just some data in session object does it. > (they occur non-deterministically, they are > extremely difficult to reproduce and analyse). > As said: The advertised behaviour when several requests modify > the same session object is that all but the first committing request get > a "ConflictError" and are retried. Everything else is a bug. > I'm agree that, if it works fine, the retrieing request method is a good solution. My problem is quasi deterministic, it crashes most of times :-( I will try to provide a example.zexp when entering the bug so it could be easier to reproduce. > Another note: it is known (though we do not yet fully understand why) > that sessions behave non-deterministically (disappear, revert to old > values) when they are read/written in "standard_error_message" (Zope's > error handling hook for failing requests). > I'm not using SESSION in standard_error_message, but symptoms are very similar. Santi Camps _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
