users@javaee-spec.java.net

[javaee-spec users] [jsr342-experts] Re: transactional methods and exceptions

From: Werner Keil <werner.keil_at_gmail.com>
Date: Sat, 11 Feb 2012 12:58:51 +0100

Bill/all,

I'd also prefer D2. Especially since java.sql.SQLException unlike JPA
exceptions does not inherit from RuntimeException, thus I guess it's
considered a checked exception, too.

Thus, if there are mixed environments where JPA and SQL exceptions may
occur in the same context, I'd prefer they also be treated equally.

Werner

On Fri, Feb 10, 2012 at 6:31 PM, Deepak Anupalli <deepak_at_pramati.com> wrote:

> 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
>
>