It looks like we're in general agreement on the transactional interceptor
approach I proposed earlier.
Aside from the more obvious open issues around naming, there is an
issue related to the handling of exceptions that we need to resolve.
The issue relates to what should happen with regard to the state of a
transaction when an exception is thrown that reaches a transactional
interceptor.
First, some background on how EJB handles container-managed transactions....
The EJB spec distinguishes between "system exceptions", which
cause the container to mark the transaction for rollback, and
"application exceptions", which by default do not cause the
transaction to be marked for rollback.
An application exception is either a checked exception (other than the
RemoteException) or a runtime exception annotated with @ApplicationException.
@Target(TYPE) @Retention(RUNTIME)
public @interface ApplicationException {
/**
* Indicates whether the container should cause the transaction to
* rollback when the exception is thrown.
*/
boolean rollback() default false;
/**
* Indicates whether the application exception designation should
* apply to subclasses of the annotated exception class.
*/
boolean inherited() default true;
}
An EJB system exception is a subclass of RemoteException or a subclass
of RuntimeException that has not been designated as an application
exception.
When the EJB container intercepts a system exception (at a business
method boundary), it causes the current transaction to be marked for
rollback. When the called method runs in the context of the caller's
transaction, the container throws the EJBTransactionRolledBackException
(or some variant thereof). If a new transaction was *started* for the
called method, the container throws the EJBException. In both these
cases, the original exception is wrappered. Application exceptions
are thrown back to the caller as is.
If the caller receives an application exception, the caller presumably
knows based on the exception type whether the exception causes
rollback or not. Unless the caller is familiar with the transaction
attribute of the called method, however, the caller doesn't know
whether its own transaction was marked for rollback or whether only
the callee's transaction was rolled back. However, the caller can
invoke the getRollbackOnly method to determine the state of its own
transaction.
In the case of a system exception, if the caller receives the
EJBException, the caller can assume that the callee's transaction was
rolled back, but that the caller's own transaction was not affected.
If the caller receives the EJBTransactionRolledBackException, the
caller knows that its own transaction was marked for rollback (and
that the callee was run within the context of that same transaction).
So much for background.... Now, what should the behavior be for
transactional interceptors?
While we could adopt the EJB approach (modulo some renaming), Bill and
I are concerned that it is too complex. (See Chapter 14 ("Exception
Handling") of the EJB 3.1 spec for the gory details.)
We propose a simpler approach along the following lines:
By default, all exceptions should result in the current transaction
being marked for rollback. If the developer believes that the
exception should not cause rollback, he or she annotates the exception
class with @DontRollbackTransaction (real name for this exception *TBD*).
The DontRollbackTransaction annotation is simply:
@Target(TYPE)
@Retention(RUNTIME)
@Inherited
public @interface DontRollbackTransaction {}
All exceptions are thrown back without any wrappering. While we can
understand the rationale for wrappering an exception that marks the
caller's transaction for rollback in a TransactionRolledbackException,
we're not convinced that this is needed. Likewise, we're not
convinced of the need to make a distinction by means of exception
wrappering as to whether the callee's transaction was rolled back.
We'd like your feedback on this and on your experience with regard
to how developers are actually making use of the current EJB facility,
particularly in view of the assumptions that we are making.
Again, we are assuming the following:
(1) It is not essential that the caller be able to identify from an
exception that it receives whether its own transaction was marked
for rollback, as the caller can use the getRollbackOnly method
to determine this.
(2) It is not essential that the caller be able to identify by means
of the exception that it receives back whether a transaction
was started on behalf of a method that it invoked, as it can
use its knowledge of the exception received and getRollbackOnly
status to determine this if it does not already know this information.
(3) Subclasses of dont-rollback exceptions will typically be dont-rollback
exceptions, and, if not, they can be defined to not extend dont-rollback
exceptions. (Note that if we receive compelling feedback from
developers to the contrary on this point, we could always add a
an element to the annotation to control this at a later time. If
we think this is at all likely, we should choose an annotation
name accordingly.)
Please post your feedback.
Other specleads should feel free to forward this message to your expert groups for
further input.
thanks,
-Linda