[ZODB-Dev] transaction bug?
Kapil Thangavelu
k_vertigo@yahoo.com
Thu, 7 Mar 2002 14:34:45 -0800 (PST)
hi folks,
i'm not entirely if this is the proper forum for this
post, if not let me know.
while working on a zodb transaction filesytem
integration layer, i noticed some curious behavior
(data corruption) when interacting with
subtransactions which i think is a bug.
take a non sub transaction (st) aware object 'foo',
register it with the transaction (i'm using the
wrapper from the zope library
lib/python/Shared/DC/ZRDB/TM.py for registration).
if a subtransaction is committed, the tpc_final of
foo's jar is called. this action belies the comment in
Transaction.py
# The _non_st_objects variable is either None or a
# list of jars that do not support subtransactions.
# This is used to manage non-subtransaction-supporting
# jars during subtransaction commits and aborts to
# ensure that they are correctly committedor aborted
# in the "outside" transaction.
iotw. with foo registered, then a call to
get_transaction().commit(1)
get_transaction().abort()
leads to a loss of data integrity.
the only distinguishing feature for a subtransaction
and a transaction from the POV of the object's jar is
the calling of tpc_vote. so this means that this can
be worked around, but i think the semantics of calling
tpc_final on non-st aware objects in a subtransaction
commit needs to be rexamined. this problem, while a
corner case is made more relevant in a zope setting,
since all the DB adapters use the TM.py interface
which doesn't expose/mention the need for testing of a
tpc_vote call flag in tpc_final.
comments welcome.
cheers
kapil
__________________________________________________
Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email!
http://mail.yahoo.com/