Provided if the Interceptor CMT and EJB CMT are made mutually exclusive, it
makes more sense to go for D2 rather than D3. D2 is much easier to perceive.
I completely agree with David.
-Deepak
> -----Original Message-----
> From: David Blevins [mailto:david.blevins_at_gmail.com]
> Sent: 31 January 2012 08:17
> To: jsr342-experts_at_javaee-spec.java.net
> Subject: [jsr342-experts] Re: transactional methods and exceptions
>
> -- for the busy --
>
> I'd probably fall into the D2 S3a A2 range, with the obvious
acknowledgment
> that anything involving an A2 approach is essentially "off" by default.
>
> Definitely D1 in result, which I'm actually not a fan of, but an A2
approach can
> get you D2 or D3 and any of the S* options in one annotation to rule them
all.
> It can also get you "bean managed rollback" without any cost. The perks
> make it the nicest option for me.
>
> -- for the interested --
>
> Some ideas on how all the D* options could be done with something in the
> S3 range:
>
> On Jan 30, 2012, at 12:40 PM, Bill Shannon wrote:
>
> > D1. By default, exceptions don't effect the current transaction.
>
> // standard @Target/_at_Retention
> public @interface Rollback {
> Class<? extends Throwable>[] value();
> }
>
> > D2. By default, exceptions cause the current transaction to be
> > marked for rollback.
>
> // standard @Target/_at_Retention
> public @interface Rollback {
> Class<? extends Throwable>[] value() default {Throwable.class};
> }
>
> > D3. By default, runtime exceptions cause the current transaction to be
> > marked for rollback; checked exceptions do not effect the current
> > transaction.
>
> // standard @Target/_at_Retention
> public @interface Rollback {
> Class<? extends Throwable>[] value() default
{RuntimeException.class,
> Error.class};
> }
>
> Obviously the D1 option is a little awkward. If we were going to have a
> separate annotation (A2) to turn on exception-based-rollback
functionality,
> it'd likely have a D2 or D3 default. My order of preference for an A2
approach
> would probably be D2 over D3. Since the user has easy control of when and
> where to apply it, I would opt for the simplest and most conservative
default
> -- less for us to explain, less for users to read. The name @Rollback
looks less
> clear when there are no parameters (D2 or D3), so maybe
> @RollbackOnException as was used before.
>
> A1 can work fine with the list approach. The downside of that is having
> "@Transaction(rollbackOnException={})" could look a little strange as a
way
> of shutting off the functionality should someone wish to implement their
> own finely controlled exception-based-rollback functionality. Also having
to
> say, "no no no no no no no no" all over your code can be very noisy,
whereas
> explicitly adding @RollbackOnException can be very self-documenting.
>
> Overall I'd be happy with any solution that allows for some easy and clear
> way to shut off the spec defined exception-based-rollback functionality so
> that someone could write their own without it feeling like a hack. A2
seems
> to fit that bill the best.
>
>
> It really does take only an afternoon to write the interceptor for any one
of
> the proposed options. Letting users have that control seems worth it. I
get a
> particularly big grin on my face imagining what a "bean validation on
> exceptions" rollback approach might look like. Would not be good for the
> spec level, but I can see it and other options becoming particularly
popular
> CDI extensions.
>
>
> -David