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