On Saturday 15 March 2003 5:40 pm, Chris McDonough wrote:
- The second is an unidentified (yet) bug in TemporaryStorage.
As a cause of the KeyError exception? Could be.... I have seen equivalent exceptions with plain FileStorage in applications that do not use sessions, so I suspect there might be a hard-to-hit zodb bug that can cause this too. (In FileStorage the equivalent exception is POSKeyError, a subclass of KeyError)
If I find and fix the TemporaryStorage bug I will let you know. In the meantime, you can probably work around this by using a different non-undoing storage to put your session data in (e.g. Berkeley, or maybe DirectoryStorage?).
It would be interesting to hear if this exception is repeatable with the session state stored in a FileStorage too.
You may see many more conflicts with this running. But maybe the data structures will not become desynchronized.
You weren't kidding about the increase in conflict errors.
Read conflicts occur if a change is committed in between the start of a transaction, and the transaction needing to load the object. A workaround to reduce the number of read conflicts is to touch the objects that are likely to change early in the transaction. -- Toby Dickenson http://www.geminidataloggers.com/people/tdickenson