[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/