openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey" <plins...@bea.com>
Subject Exceptions thrown from callbacks
Date Thu, 01 Feb 2007 23:27:01 GMT
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.

Mime
View raw message