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)


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.


Zope maillist  -  [EMAIL PROTECTED]
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-dev )

Reply via email to