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