Date: Mon, 23 Jan 2012 15:20:31 +0100
Linda/all,
Sorry I haven't been too responsive on that list lately.
The annotations sound good to me. An annotation ending on "Exception"
without being an exception may seem a bit odd, but I guess I could get used
to it, if most people think it's OK.
What we already briefly discussed following the talk by TypeAnnotation (JSR
308) Spec Leads, is, that more and more annotations affect a larger part of
the Java platform. And where anything like "ApplicationException" means, it
affects the application, and it may be of use not just to EJB, but JSF, CDI
or maybe even other platforms (SE, ME) please let's keep that in mind
before we create redundancy like before, having some annotations in EJB or
here and similar ones in CDI or JSF.
Those annotations JPA uses together with BeanValidation already could be
affected by any standard annotation proposed by 308 and OpenJDK. Nothing is
written in stone, but they proposed something like @NonNull where
BeanValidation already got the @NotNull constraint. Not only a redundancy,
if it came like that, but even a slight variation, sounds to me like
"Annotation Hell" we should try to avoid, not just in EE7 and 8[?]
Werner
On Tue, Jan 10, 2012 at 9:14 PM, Linda DeMichiel <linda.demichiel_at_oracle.com
> wrote:
>
> 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 EJBTransactionRolledBackExcept**ion
> (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 EJBTransactionRolledBackExcept**ion, 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
>
-- Werner Keil | JCP Executive Committee Member (ME) | Eclipse UOMo Lead Twitter @wernerkeil | #Java_Social | #EclipseUOMo | #OpenDDR Skype werner.keil | Google+ gplus.to/wernerkeil * M-Day: February 1 2012, Frankfurt, Germany. Werner Keil, JCP EC Member, OpenDDR Evangelist will discuss "Mobile Web Development" * Social Media Week: February 13-17 2012, Hamburg, Germany. Werner Keil, JCP EC Member, designated Social JSR Spec Lead will discuss "Java Social" * Mobile Developer Conference: February 14 2012, Hamburg, Germany. Werner Keil, JCP EC (ME) Member, OpenDDR Evangelist will present "OpenDDR"
(image/gif attachment: 322.gif)