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*).
>>