[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ojb-user
Subject:    (ODMG) Transaction.abort() vs. object rollback
From:       "Steve Clark" <sclark () euler ! cr ! usgs ! gov>
Date:       2004-04-27 19:20:54
Message-ID: 16526.45718.70793.374814 () euclid ! tat ! fws ! gov
[Download RAW message or body]

The way I read the Javadocs, if I make some changes to persistent
objects which are locked to an ODMG Transaction, and then
Transaction.commit() fails, e.g. due to a database constraint
violation, then the objects in memory should be rolled back to their
state prior to the Transaction.  Is my understanding correct?

I am seeing the following behavior:

tx1.begin();
parent = fetchParent();
tx1.commit();
assert(parent.getChildren().size() == 1);

tx2.begin();
child = new Child();
child.setSomeAttributeToInvalidValue();
tx.lock(parent, WRITE);
parent.addChild(child);
try {
    tx2.commit();
}
catch TransactionAbortedException {
    assert(parent.getChildren().size() == 2);
}

My child object contains a value which violates a database
constraint.  On commit(), the Transaction, as expected, throws
TransactionAbortedException.  But the new Child object is still in
the parent's collection of children, so future Transactions
involving this parent will fail (including deletePersistent(),
which attempts to insert the missing Child, not realizing that it
will be immediately deleted).

Is this the correct behavior?
Should this be the expected behavior?
If the answer to both questions is yes, then I think the Javadocs need
some clarification.

Finally, if this is the correct behavior, what are others doing to
address this situation?

I'm using CVS HEAD as of a week or so ago.

thanks,
--
Steve Clark
Technology Applications Team
Natural Resources Research Center/USGS
sclark@support.tat.fws.gov
(970)226-9291

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org

[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic