[Zope-dev] problems with TM.py

Hung Jung Lu hungjunglu@hotmail.com
Thu, 02 Mar 2000 21:33:04 PST


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