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