Skip to main content

[jsr342-experts] Re: transactional methods and exceptions

  • From: David Blevins <david.blevins@...>
  • To: jsr342-experts@...
  • Subject: [jsr342-experts] Re: transactional methods and exceptions
  • Date: Mon, 30 Jan 2012 18:46:52 -0800

-- 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/@Retention
    public @interface Rollback {
        Class<? extends Throwable>[] value();
    }

> D2. By default, exceptions cause the current transaction to be
>    marked for rollback.

    // standard @Target/@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/@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



[jsr342-experts] transactional methods and exceptions

Bill Shannon 01/30/2012

[jsr342-experts] Re: transactional methods and exceptions

David Blevins 01/31/2012

[jsr342-experts] Re: transactional methods and exceptions

Deepak Anupalli 01/31/2012
 
 
Close
loading
Please Confirm
Close