Responses in-line...
> -----Original Message-----
> From: Linda DeMichiel [mailto:linda.demichiel_at_oracle.com]
> Sent: Tuesday, July 17, 2012 1:37 PM
> To: jsr342-experts_at_javaee-spec.java.net
> Cc: Paul Robinson
> Subject: [jsr342-experts] Re: [javaee-spec users] Re: transactional
interceptors
> and exceptions
>
> Hi Paul, Reza, all,
>
> I think you raise good points. Bill and I did contemplate whether to
propose that
> we provide for S2c functionality as well. S2c alone (in the absence of
S3c) didn't
> seem flexible enough to us. Also, the clear majority of the people who
weighed
> in preferred an S3c approach.
>
> Before we go further on this, however, I think there are a number of
issues that
> we need to consider:
>
> * The new transactional interceptors are providing a somewhat different
> functionality than EJB CMT. While the functionality is similar, users
will need to
> understand the differences. For example, while EJB interposes on every
business
> method invocation, transactional interceptor interpositioning will only
occur
> where the user has specifically indicated that it should. Further, we're
not
> proposing that we treat EJB exceptions specially. (Actually, we think it
would be
> an unnecessary complication to do so). Thus, EJB exceptions (like the
> RemoteException) that would cause transactions to be marked for rollback
> under EJB will not cause this behavior when they reach a transactional
> interceptor unless the rollbackOn element indicates that they should.
Also,
> unlike with EJB, exceptions causing rollback won't be wrapped.
[Reza Rahman] This seems very sensible.
>
> * While we're open to considering an annotation that could be applied to
an
> exception class to indicate that transactions should not be marked for
rollback
> for exceptions of that type, we don't think that we should embed knowledge
of
> the EJB @ApplicationException annotation into the implementation of the
new
> transactional interceptors. Any new annotation would then still need to
be
> added to those EJB exceptions to achieve the behavior of
> @ApplicationException with the new transactional interceptors. We think
that
> defining a different annotation is the right thing to do if we are
planning for
> migration *from* EJB.
[Reza Rahman] This is sensible. I would think having a similar annotation in
the javax.transaction package instead of javax.ejb should do the trick...
>
> * If we add such an annotation, we would need to define the interaction
with
> the rollbackOn/dontRollbackOn elements. We are currently assuming that
the
> rollbackOn/dontRollbackOn values would override the effect of such an
> annotation.
[Reza Rahman] That seems sensible.
>
> * Finally, before adding more flexibility/functionality we'd like to be
sure that
> our tradeoff would be the right one to make in view of
> the further complexity that it would introduce. Note also, that
> this is something that we could add down the road if we received such
feedback
> from developers.
[Reza Rahman] Understood. Personally, it doesn't seem that complicated to
me. As Paul verbalized, it does worry me that someone coming from an EJB
background might find it odd to not find an @ApplicationException
equivalent. I've personally found @ApplicationException useful.
>
> What do all of you think?
>
> thanks again,
>
> -Linda
>
>
> On 7/14/2012 7:46 AM, Paul Robinson wrote:
> > Linda,
> >
> > So it looks like we are settling on adopting almost the same approach
> > for exception handling as that currently provided by EJB. I'll quote my
previous
> email on this:
> >
> > My personal thoughts are that we really have to provide the same
behaviour
> as that provided by EJB transactional
> > intercepters (D3 S2c A1). As this is a JEE related specification,
users are going
> to find it very strange that the
> > semantics of these, seemingly identical, annotations are different.
More
> dangerously, there are going to be many
> > users who don't know that the semantics around exception handling
and
> rollback are different, potentially causing
> > the behaviour of there application to change in unexpected ways.
> >
> >
> > However, the proposal does differ in how non-default behaviour is
> > expressed. By offering S3c rather than S2c, we are going to cause
> > potentially unexpected behaviour for those migrating away from EJB. I
> > would expect that many developers will leave the annotations on the
> > Exception classes, expressing a change from the default, and expect
> > those to be adhered to. Unfortunately, with the S3c approach these old
> annotations will be ignored along with the developer's intend behaviour.
My
> feeling is that in many (most?) applications, this is the type of bug that
is unlikely
> to be detected during testing and is likely to surface at runtime.
> >
> > My understanding is that EJB and the TX interceptors will co-exist for
> > some time, so we can't prevent this type of issue by simply preventing
the EJB
> related transaction annotations being placed on an Exception class.
> >
> > Do we really need to move away from the accepted and well understood
> behaviour of EJB?
> >
> > Paul.
> >
> >
> > On 13 Jul 2012, at 02:00, Linda DeMichiel wrote:
> >
> >>
> >> We'd like to close out the remaining open issue as to how to specify
> >> the behavior of transactional interceptors when an exception is
> >> thrown that reaches such an interceptor.
> >>
> >> After tallying and weighing the responses that we received from
> >> polling this group, from our other Java EE specleads, and from
> >> members of the community, we propose that we take the "D3 S3C A1"
> >> approach
> >> -- which is consistent with the majority of the opinions we received.
> >> (To refresh your memory, please see Bill's earlier message, appended
> >> below.)
> >>
> >>
> >> The proposal is the following:
> >>
> >> By default, "application exceptions" (i.e., checked exceptions /
> >> instances of Exception and its subclasses other than
> >> RuntimeException) do not result in the transactional interceptor
> >> marking the transaction for rollback, and instances of RuntimeException
and
> its subclasses do.
> >>
> >> This default behavior can be overridden via the Transactional
> >> annotation. More specifically, we propose adding to the Transactional
> >> annotation an element to specify additional exceptions that result in
> >> the interceptor marking the transaction for rollback and an element
> >> to specify exceptions that do not cause the interceptor to mark the
> >> transaction for rollback.
> >>
> >> For example:
> >>
> >> @Inherited
> >> @InterceptorBinding
> >> @Target({TYPE, METHOD})
> >> @Retention(RUNTIME)
> >> public @interface Transactional {
> >> TxType value() default TxType.REQUIRED; Class[] rollbackOn() default
> >> {}; Class[] dontRollbackOn() default {}; }
> >>
> >> When a class is specified for either of these elements, the
> >> designated behavior applies to subclasses of that class as well.
> >> If both elements are specified, dontRollbackOn takes precedence.
> >>
> >>
> >> Examples:
> >>
> >> @Transactional(rollbackOn={Exception.class})
> >>
> >> will override behavior for application exceptions, causing the
> >> transaction to be marked for rollback for all application exceptions.
> >>
> >>
> >> @Transactional(dontRollbackOn={IllegalStateException})
> >>
> >> will prevent transactions from being marked for rollback by the
> >> interceptor when an IllegalStateException or any of its subclasses
> >> reaches the interceptor.
> >>
> >>
> >> @Transactional(
> >> rollbackOn={SQLException.class},
> >> dontRollbackOn={SQLWarning.class}
> >> )
> >>
> >> will cause the transaction to be marked for rollback for all runtime
> >> exceptions and all SQLException types except for SQLWarning.
> >>
> >>
> >> Note that we are assuming that there is no special, built-in
> >> knowledge about EJB application exceptions (i.e., runtime exceptions
> >> annotated with @ApplicationException). As far as the interceptor is
> >> concerned, these would be treated just as any other runtime
> >> exceptions unless otherwise specified.
> >>
> >> Please let us know if you have any additional feedback on this.
> >>
> >> thanks!
> >>
> >> -Linda
> >>
> >> --------------------------------
> >>
> >>
> >> On 1/30/2012 12:40 PM, Bill Shannon wrote:
> >>> One of the issues with the new transactional annotations we're
> >>> proposing is how to handle exceptions that are thrown out of a
> >>> transactional method.
> >>>
> >>> The first choice is, what should the default behavior be?
> >>> We have these options:
> >>>
> >>> D1. By default, exceptions don't effect the current transaction.
> >>> D2. By default, exceptions cause the current transaction to be
> >>> marked for rollback.
> >>> D3. By default, runtime exceptions cause the current transaction to
> >>> be marked for rollback; checked exceptions do not effect the current
> >>> transaction.
> >>>
> >>> After deciding on the default behavior, we have these choices for
> >>> overriding the default:
> >>>
> >>> S1. You can't override the default.
> >>> S2a. You can override the default by annotating exceptions that
> >>> should cause rollback. (E.g., with @ApplicationException) S2b. You
> >>> can override the default by annotating exceptions that should not
> >>> cause rollback.
> >>> S2c. You can override the default by annotating exceptions that
> >>> should cause rollback and by annotating exceptions that should not
> >>> cause rollback. (E.g., with a "rollback" element in
> >>> @ApplicationException)
> >>> S3a. You can override the default by annotating class or methods
> >>> with a list of exceptions that should cause rollback.
> >>> S3b. You can override the default by annotating class or methods
> >>> with a list of exceptions that should not cause rollback.
> >>> S3c. You can override the default by annotating class or methods
> >>> with a list of exceptions that should cause rollback, and a list of
> >>> exceptions that should not cause rollback.
> >>>
> >>> The S2c and S3c options have these additional options:
> >>>
> >>> A1. The rollback behavior is an element(s) of the base annotation.
> >>> A2. The rollback behavior is a separate annotation(s).
> >>>
> >>> (Note that S2 and S3 are not mutually exclusive.)
> >>>
> >>> In all cases, the behavior for a given exception is determined by
> >>> looking for an annotation or specification for that particular
> >>> exception and if none is found traversing the superclass chain.
> >>> That is, the exception behavior is always "inherited".
> >>>
> >>>
> >>> My understanding is that Spring supports D3 S3c A1.
> >>> (In addition, Spring allows specifying the exceptions as either
> >>> Class objects or String names, which seems like overkill.)
> >>>
> >>> EJB supports D3 S2c A1 for local beans.
> >>>
> >>> I believe Reza was suggesting D3 S2c S3c A1.
> >>>
> >>> I believe David was suggesting D1 S3a A2.
> >>>
> >>> Our goal with these new transactional annotations was to come up
> >>> with something that was simple, where "simple" means both "has few
> >>> concepts" and "is easily understood by developers". In addition to
> >>> being simple, it needs to satisfy a large percentage of the use cases.
> >>>
> >>> The simplest is D1 S1, but I don't think that matches what
> >>> developers will expect.
> >>>
> >>> Given the prevalence of D3 in existing systems, D3 S1 would be very
> >>> simple. Unfortunately, we're told that many developers are moving
> >>> towards using runtime exceptions for everything, so D3 S2b would be
> >>> a relatively simple approach.
> >>>
> >>> The major advantage I see for the S3 options is that they allow you
> >>> to more easily override the default behavior for "system" exceptions.
> >>> For example, if your method throws IllegalArgumentException in a
> >>> case where it knows that it hasn't modified the state of the
> >>> transaction, you might like that exception to *not* cause the
> >>> transaction to be marked for rollback. With S2, you would have to
> >>> subclass the exception and mark the subclass. But of course that
> >>> does have the advantage that other uses of that exception in methods
> >>> you call have the default behavior.
> >>>
> >>> Which options do you prefer?
> >
> > --
> > Paul Robinson
> > Web service transactions lead
> > paul.robinson_at_redhat.com <mailto:paul.robinson_at_redhat.com>
> >
> > JBoss, a Division of Red Hat
> > Registered in England and Wales under Company Registration No.
> > 03798903
> > Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt
> > Parson (USA), Charlie Peters (USA)
> >