Re: [Zope-dev] problems with TM.py
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
Hi Hung - I removed the zope@zope.org field in my reply. No need to crosspost there. On Thu, 2 Mar 2000, Hung Jung Lu wrote:
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.
You are right. A non-mutable attribute should not present any problems. However one can share data between threads using mutable class attributes (plus proper protection): class A: shared=[] a=A() a.shared.append(1) etc ....
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. :(
Any attribute begining with _v_ is volatile and does not trigger the ZODB if modified.
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".
ZODB does not care about HTTP requests. get_transaction().begin() and get_transaction().commit() define the boundaries of the transaction. However the Zope framework automatically begins a transaction at the begining of the HTTP request and commit (if no error occurs) at the end of the request. In my view the transaction manager should be decoupled from ZODB entirely so we can use it easily for whatever applications might need transactional support. I was hoping that functionality would be provided by subclassing TM.py and overloading the proper methods. Unfortunately it has siteeffects. _registered becomes an instance attribute the moment _register() is called which triggers __getattr__which in turn marks the instance as changed and ZODB writes a new copy at the end of the transaction. Thats why I renamed it to _v_registered but only Gim knows what other subtle problems this might create. Pavlos
participants (2)
-
Hung Jung Lu -
Pavlos Christoforou