> -----Original Message-----
> From: Bill Shannon [mailto:bill.shannon_at_oracle.com]
> Subject: [jsr342-experts] Re: transactional methods and exceptions
>
> Just so I'm clear...
>
> Previously you said you preferred D3 S2b S3c A2.
>
> Now you're saying that you prefer the same as David - D2 S3a A2.
>
> Correct?
Yes rite. I guess making way to a newer and better approach brings the
paradigm shift.
>
> Deepak Anupalli wrote on 02/10/12 09:31:
> > 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
> >