On Fri, 7 Jul 2000, Paul Gresham wrote:
Hi, Yep, I'm definitely running 0-4-0, I think the fact that I did something naughty caused the rename (and therefore the commit) to fail, when it expected to work. An exception in the commit then caused Zope to stop all commits. What is worrying is that someone much more naughty than I am, may just do something similar on our live system (Once this goes live)
Paul When I was testing FSSession-0-4-0 before release I created all sorts of weird situations and at least I got the impression that even under those situations FSSession would behave ok. I suppose I could make it foolproof by trying to serialize the contents everytime someone makes changes. This would guarantee that no exception will be raised during commit, but as I understand it it should be ok if an exception is raised during the first phase of commit (ie during tpc_begin). Zope should remain in a consistent state and the transaction machinery should clean up things ok, if something bad happens during the first phase of commit. It is only if an exception is raised in the second phase of commit that Zope refuses to carry on more transactions. In any case please send me your setup that creates such a problem with FSSession0.4.0 so I can look into it. If you want to restrict the kind of objects that your users will store in FSSession you could swap _dump and -load for the equivalent marshal ones. Pavlos