On Tue, 2003-03-18 at 14:01, Toby Dickenson wrote:
On Tuesday 18 March 2003 6:12 pm, Chris McDonough wrote:
I'm thinking that I also may just need to move the housekeeping duties to a separate scheduled thread that only happens when the system is "not busy" (e.g. when the asyncore poll select timeout is reached maybe) in order to reduce the potential for conflicts.
Thats hard to define, when zeo is installed.
It would only make sense for shared session data if the housekeeping thread was enabled on a single ZEO client in a cluster. Of course this scenario has its own configuration and management difficulties.
But I'm not sure what else to do, and I still don't understand what is causing the KeyErrors in the storage code. Sigh.
Ive never looked at nor used your Sessioning support, but I am interested in things that can cause (POS)KeyErrors in Storages.....
This might not be a storage bug. There are several known corner cases in zodb that mean semi-legitimate applications can cause KeyErrors. DirectoryStorage tries to guard against them, and will raise a DanglingReferenceError rather than commit a transaction that will cause a POSKeyError when read. Can the problem be reproduced using DirectoryStorage? (without the "low consistency connection")
That's a fine question. ;-) John, did you see these Key Errors happen under a storage other than TemporaryStorage (e.g. if the session data container is in the main database)? I will check myself as well when possible. Dieter also observed that this may be a behavior specific to mounted storages, so I will need to try that as well. - C