On Wed, 2004-09-15 at 00:49, Chris McDonough wrote:
On Wed, 2004-09-15 at 00:01, Richard Jones wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 15 Sep 2004 08:11 am, Richard Jones wrote:
On Tue, 14 Sep 2004 05:15 pm, Richard Jones wrote:
Something I've done in the interim, which I *think* will help things, if I'm reading the various tracker issues and email threads correctly, is my standard_error_message DTML page doesn't email the REQUEST to me (and hence the SESSION) any more, as that accesses the Transience stuff during exception handling, which is apparently bad.
Several new POSKeyErrors overnight tell me that I was barking up the wrong tree here. Sigh.
I just realised that the error_log object has the REQUEST/SESSION information in it, so my changes would have had no impact.
Yikes. That's actually really bad. I will change REQUEST's __str__ to prevent a session data object from being created as a side effect!
False alarm, sorry. A session data object doesn't actually get created as a result of str(REQUEST) -- the 'SESSION' item in the request remains "lazy" in this case. Whew. ;-) FYI, if you see something like: SESSION <bound method SessionDataManager.getSessionData of <SessionDataManager instance at f3a87710>> ... in a REQUEST rendering, it indicates a session that is still "lazy", which means a session hasn't actually been created during this request. OTOH, if you see something like: SESSION id: 10952247771174881012, token: 06504336A1fW8kmVMHc, contents: [('count', 0)] ... in the log, it means that a session was created at some point during the request. A session data object always gets created as a side effect of REQUEST.keys(), REQUEST['SESSION'], REQUEST.SESSION, REQUEST.get('SESSION') or REQUEST.has_key('SESSION'), or when sdm.getSessionData() is called explicitly. But unless you did any of the latter in the email, you're no better or worse off than when you started really. Not that you would have been bad off anyway. ;-) It *should* be fine to do transience operations during an exception (the publisher behavior that made it not so was fixed before 2.7.1). The worst thing that should be able to happen is that the standard error message itself errors out with a conflict error, the emergency error handler runs as a result, and renders that conflict error to the requesting user agent. - C