pavlos christoforou <pavlo-@gaaros.com> wrote:
TM.py defines _registered as a class variable which seems to hold the state of an instance (whether it is registered with the transaction manager or not). method _register() registers the instance with the TM depending on the content of the _registered attribute. this however seems to have the additional effect to set the instance as changed and therefore and therefore a new version is stored in the ZODB. Additionally as _registered is defined as a class variable it is shared among threads and therefore one thread can interfere with the state of another.
I would like to understand the source of your problem, too. However, I think there is a misunderstanding here. In TM.py, _registered is a class data attribute, which is typically a trick for "initializing" Python instance data attribute. That is, unless you explicitly do something like TM._register = 1 the class variable would never change. That is, TM._register is always None. Always always. So there should not be any problem in thread interference. If x is an instance of TM (or an instance that has TM as an interface, in the case of multiple inheritance), if you look at the dictionary of x, i.e: x.__dict__ , you will see that initially x does not have an attribute _register in its own dictionary. However, x._register is a valid reference, because it borrows from the class attribute. The statement: print x._register would print out 'None'. As soon as you assign a value to x._register = 1 you create an attribute in the dictionary of x. That is, a new item is added into x.__dict__ , which is totatally independent of TM._register. So TM._register remains as None.
I have changed all references to _registered in TM.py to _v_registered and my problem (creating new versions for every call to FSSession) is solved, but I am not sure what other classes use TM.py. Also I am thinking of changing _v_registered to an instance attribute instead of a class attribute. Any thoughts?? Is it a bug of TM.py
I'd like to take a look into it, too. But first I'll have to learn what the flags _v_registered and _register mean. :( I don't even understand what is a "transaction" in the sense used by the transaction manager. If I understand correctly, the definition of "transaction" that you would like to use is one single HTTP transaction, which lasts from the beginning of a foreign HTTP client request till the end of Zope sending out the reply. The question is: is this the same definition of "transaction" as used by the transaction manager? Why would anything be stored in ZODB?!? The HTTP "transaction" should not have anything to do with ZODB database "transaction". The "versions" that are stored in ZODB, are they FSSESSION objects? I'd like to look into all this. :) regards, Hung Jung ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com