Is there an easy way for a python object to know when a web request has completed? For example, if I have an object that needs to do some setup and tidy up around operations, I want to group operations together if possible, but I don't want to delay the tidy up until the object is thrown out of the cache. I have tried using the mixin class Shared.DC.ZRDB.TM and defining _abort, _finish, but without much success. The first time I call _register the _finish method is called as I expected, but the transaction forces a commit, which writes the object to the ZODB with _registered set to 1 so that subsequent attempts to start a transaction fail. Besides, this forces a transaction on the ZODB which I would really rather avoid. -- Duncan Booth duncan@dales.rmplc.co.uk int month(char *p){return(124864/((p[0]+p[1]-p[2]&0x1f)+1)%12)["\5\x8\3" "\6\7\xb\1\x9\xa\2\0\4"];} // Who said my code was obscure? http://dales.rmplc.co.uk/Duncan
Duncan Booth wrote:
Is there an easy way for a python object to know when a web request has completed?
There is a subtle difference between when a web request 'ends' and when a transaction gets commited. They usualy occour relativly simultaneously to the user, but underneath they are two different operations.
For example, if I have an object that needs to do some setup and tidy up around operations, I want to group operations together if possible, but I don't want to delay the tidy up until the object is thrown out of the cache.
I think perhaps you are looking for __bobo_before__ and __bobo_after__. If your object defines these two methods then the first will be called before the object is called by ZPublisher, and the second will be called after (ZPublisher used to be called Bobo).
I have tried using the mixin class Shared.DC.ZRDB.TM and defining _abort, _finish, but without much success. The first time I call _register the _finish method is called as I expected, but the transaction forces a commit, which writes the object to the ZODB with _registered set to 1 so that subsequent attempts to start a transaction fail. Besides, this forces a transaction on the ZODB which I would really rather avoid.
Yeah, I wouldn't mess too much with the transactions... -Michel
Yeah, I wouldn't mess too much with the transactions... Thanks for the advice. I left this for a few hours then went back and revisited it, and I think I now have what I wanted working with the TM mixin class. I may check out __bobo_before__ and __bobo_after__ as well though for comparison.
Basically the answer I came up with to my own question is as follows: Shared.DC.ZRDB.TM is basically incompatible with the persistence mechanism, however if you have a non-persistent class it does what I expected. My code was already split between a front-end and a back-end class where the front-end class is persistent, and the back- end class handles the actual work. The back-end class can safely mixin both TM, and Sync.Synchronized (which is also incompatible with persistence) and everything works as I expected. -- Duncan Booth duncan@dales.rmplc.co.uk int month(char *p){return(124864/((p[0]+p[1]-p[2]&0x1f)+1)%12)["\5\x8\3" "\6\7\xb\1\x9\xa\2\0\4"];} // Who said my code was obscure? http://dales.rmplc.co.uk/Duncan
participants (2)
-
Duncan Booth -
Michel Pelletier