sorry for ignore your first post. Don't hesitate to post again and again and ... ;-)
Steve Clark wrote:
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?
This was changed between rc5 and rc6 (see release notes, odmg restore). The problem was that the restore function (rollback method in ObjectEnvelope class, line 432 commented out) in odmg implementation only can guarantee the restore of persistent fields of the main object (non persistent fields are not restored). Modified refereneces, e.g. removed objects of a 1:n reference collection can't be restored.
Thus I disabled this feature, instead all modified objects will be removed from cache, so it is guaranteed that ODMG/OJB return a valid object when called next.
Where in javadocs did you read that? This should be fixed.
regards, Armin
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
