[Zope-dev] problems with TM.py

[Pavlos Christoforou]

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