Thanks for the clarification.
The feedback that I've gotten in past has been that exceptions should by default result in
transactions being marked for rollback. The proposal takes that approach as well, but
allows exceptions to be specified as not doing so by means of the annotation.
I haven't heard anyone ask for being able to specify rollback behavior dynamically by setting
a property on the exception. Calling setRollbackOnly of course can be done in any case.
What do the rest of you think?
-Linda
On 1/10/2012 12:49 PM, Jeff Genender wrote:
> I'll clarify…
>
> Especially in interceptors, the ability to be generic in flagging a rollback condition is important since the interceptor acts more as a plugin to the application, and may have little business logic understanding of the nature of Exception. Since it's an interceptor, it may need to make a decision at runtime (based on perhaps metadata associated with the exception) whether the exception is something that should have the transaction marked as a rollback condition or not.
>
> The annotation is an all-or-nothing with respect to transaction marking and I think there should be an ability to do this at runtime via an API call or setting a property on the exception (or transaction).
>
> I hope that help clarify what I mean a bit more?
>
> Thanks,
>
> Jeff
>
>
>
> On Jan 10, 2012, at 1:40 PM, Linda DeMichiel wrote:
>
>>
>>
>> On 1/10/2012 12:24 PM, Jeff Genender wrote:
>>> For a worst case scenario, I think marking them for rollback is best (just to be safe). I am not convinced about the
>>> annotation because what is this needs to be decided at runtime?
>>>
>>
>> The application can always invoke setRollbackOnly in any case. (I'm not sure I'm following you though....)
>>
>>> Was there any thought to a transaction marking bean attribute in the exception so it could be handled at runtime as
>>> well? Although testing a parent class could work, it doesn't alleviate the ability to be semi generic on deciding
>>> whether as an interceptor to flag the transaction as a rollback or not. I think a flag could do the trick pretty nicely.
>>>
>>
>> I'm not following you here. Could you expand upon this to clarify?
>>
>> thanks,
>>
>> -Linda
>>
>>
>>> Jeff
>>>
>>>
>>> On Jan 10, 2012, at 1:14 PM, Linda DeMichiel wrote:
>>>
>>>> class with @DontRollbackTransaction (real name for this exception *TBD*).
>>>
>