It seems like we've reached consensus around the following behavior at least:
1. if a callback throws an exception during commit(), wrap in RollbackException and roll back the transaction. 2. if a callback throws an exception during some non-commit() operation, do not wrap the exception, and mark the transaction for rollback. It turns out that this is exactly the current behavior. I just checked in some test cases to exercise this, since the CTS has an outage here now. -Patrick -- Patrick Linskey BEA Systems, Inc. _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. > -----Original Message----- > From: Patrick Linskey > Sent: Thursday, February 01, 2007 3:27 PM > To: open-jpa-dev@incubator.apache.org > Subject: Exceptions thrown from callbacks > > Hi, > > There's a bit of ambiguity in the spec about what should > happen when an > exception is thrown from a callback. > > I propose that we change OpenJPA's behavior to always wrap exceptions > thrown from callbacks in a RollbackException. Additionally, I propose > that if a callback is thrown from a direct flush() call or a find() or > other data load, we should mark the transaction for rollback > instead of > immediately rolling back the transaction. > > > Details: > > Section 3.5 says: > > "Lifecycle callback methods may throw unchecked/runtime exceptions. A > runtime exception thrown by a callback method that executes within a > transaction causes that transaction to be rolled back." > > 3.5.6: > > "Lifecycle callback methods may throw runtime exceptions. A runtime > exception thrown by a callback method that executes within a > transaction > causes that transaction to be rolled back. No further > lifecycle callback > methods will be invoked after a runtime exception is thrown." > > 3.7: > > "The PersistenceException is thrown by the persistence provider when a > problem occurs. [...] All instances of PersistenceException except for > instances of NoResultException and NonUniqueResultException will cause > the current transaction, if one is active, to be marked for rollback." > > ... > > "The RollbackException is thrown by the persistence provider when > EntityTransaction.commit() fails. > > > So.... in my opinion, this means that if a callback fails during > commit(), the exception thrown by the callback clearly should > be wrapped > in a RollbackException. It is less clear to me what should happen if a > callback fails at some other time, such as during a find() call. In my > opinion, we should be wrapping the user-thrown exceptions in > RollbackExceptions all the time. > > Further, I think that 3.7 trumps 3.5.6, so if an exception is thrown > from a callback during a find(), we should be marking the transaction > for rollback, rather than actually rolling it back. > > I've got changes in place that implement the behavior I just > described. > The CTS tests surrounding this issue have been excluded, due to the > ambiguity in the spec. > > Thoughts? > > -Patrick > > -- > Patrick Linskey > BEA Systems, Inc. > > ______________________________________________________________ > _________ > Notice: This email message, together with any attachments, > may contain > information of BEA Systems, Inc., its subsidiaries and > affiliated > entities, that may be confidential, proprietary, > copyrighted and/or > legally privileged, and is intended solely for the use of the > individual > or entity named in this message. If you are not the intended > recipient, > and have received this message in error, please immediately > return this > by email and then delete it. >
