Does anybody have any insight on the post-abort state of persistent
objects? I'm in a bit of a bind if my understanding of this is
correct.
thanks,
-steve
> From: "Steve Clark" <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: (ODMG) Transaction.abort() vs. object rollback
> Date: Tue, 27 Apr 2004 13:20:54 -0600
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
[EMAIL PROTECTED]
(970)226-9291
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Steve Clark
Technology Applications Team
Natural Resources Research Center/USGS
[EMAIL PROTECTED]
(970)226-9291
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
