FYI…
I prefer the same as David as well...
Jeff
On Feb 10, 2012, at 12:05 PM, Bill Shannon wrote:
> 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
>>
>