Hi All, I had some real problems with FSSession tonight. The first problem was when the FSSession tried to load, it would get an error along the lines of failed to import Acquisition. Next step was when the user session tried to rename and the file wasn't there. This threw in error in a Zope commit transaction, and rendered the site useless until a restart was performed (this was correct action by Zope, i.e. all commits are blocked to avoid the database becoming more screwed after a commit fails). First thing I did was put a try around the dump to stop it from throwing an error if the file doesn't exist. This is certainly a preferred option for us, as it does not affect the function of the FSSession at all (Except that one session is obviously now duff). Second thing in tracking down the culprit, I finally figured out that what I was doing was quite naughty. Basically creating an option for the user to return to the site and have his/her name already entered into the login screen. The mistake was putting AUTHENTICATED_USER into FSSession, it basically tried to store the object, when all I wanted was the string username! Oops! Regards Gresh
Paul Are you running FSSession0.4.0? If not please upgrade. The problems you mention below have been corrected. Nevertheless the first problem you descripe is not really related to FSSession. What happens is that certain Zope objects that can be pickled should not be stored in FSSession. Initially FSSession used marshal to serialize python objects, which is faster and does not allow storing of instances etc. I moved to pickle at the users request but one should be careful what he/she stores in FSSession. FSsession-0.4.0 should not raise an exception in tpc_finish. If I understand Zope's two phase commit mechanism, it is ok to raise an exception in tpc_begin (which corresponds to the 'polling' stage i believe) but not in tpc_finish. So now potential problems like full filesystem, unpicklable instances etc should be caught in tpc_begin. Pavlos
Pavlos Christoforou wrote:
Paul
Are you running FSSession0.4.0? If not please upgrade. The problems you mention below have been corrected. Nevertheless the first problem you descripe is not really related to FSSession. What happens is that certain Zope objects that can be pickled should not be stored in FSSession. Initially FSSession used marshal to serialize python objects, which is faster and does not allow storing of instances etc. I moved to pickle at the users request but one should be careful what he/she stores in FSSession.
FSsession-0.4.0 should not raise an exception in tpc_finish. If I understand Zope's two phase commit mechanism, it is ok to raise an exception in tpc_begin (which corresponds to the 'polling' stage i believe) but not in tpc_finish. So now potential problems like full filesystem, unpicklable instances etc should be caught in tpc_begin.
Pavlos
Pavlos Christoforou wrote:
Paul
Are you running FSSession0.4.0? If not please upgrade. The problems you mention below have been corrected. Nevertheless the first problem you descripe is not really related to FSSession. What happens is that certain Zope objects that can be pickled should not be stored in FSSession. Initially FSSession used marshal to serialize python objects, which is faster and does not allow storing of instances etc. I moved to pickle at the users request but one should be careful what he/she stores in FSSession.
FSsession-0.4.0 should not raise an exception in tpc_finish. If I understand Zope's two phase commit mechanism, it is ok to raise an exception in tpc_begin (which corresponds to the 'polling' stage i believe) but not in tpc_finish. So now potential problems like full filesystem, unpicklable instances etc should be caught in tpc_begin.
Pavlos
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) Regards Paul
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
participants (2)
-
Paul Gresham -
Pavlos Christoforou