I'm not sure there is any value to my reiterating my views in this
context, but it feels like I should (if I am mistaken, I apologize in
advance)...
This is generally not something I would ever say, but in this case, I
think it's best to not "fix" what's not "broken". This is a part of EJB
(and Spring, Seam, Guice, etc) that most people do not have a problem
with. I think we should just look to standardize what's already out
there and "works" instead of doing too much re-thinking (maybe with a
bit of community feedback).
On 2/17/2012 6:56 PM, Bill Shannon wrote:
> This is part of what I'm looking for opinions on - what *should* the
> goal be? And based on what you think the goal should be, what choices
> should we make?
>
> I think a lot of people who would use this new facility are already
> familiar with either the existing Java EE transaction support in EJB,
> or are familiar with the existing Spring transaction support.
>
> I suppose we should hope that this will also attract developers who
> haven't considered Java EE before, and are not familiar with how
> it currently works.
>
> But are we trying to make this "idiot proof" for people who can barely
> spell "transaction"? I don't know. What do you think? And if we did
> so, would that make it harder to use for skilled developers?
>
>
> Jim Knutson wrote on 02/17/12 15:26:
>> What is the goal? Transactions are all about protecting data
>> integrity when things go wrong. One of the possibilities is
>> that a developer gets sloppy or lazy. If the intent is that
>> transactions should protect against sloppy or lazy developers,
>> then I would think that D2 and S3c are required. In other
>> words it lowers the bar for skills while protecting data.
>>
>> On the other hand, if we are trying to make it easier for
>> the skilled developer, then perhaps D3 S3c.
>>
>> Bill Shannon<bill.shannon_at_oracle.com> wrote on 01/30/2012 02:40:13 PM:
>>> The first choice is, what should the default behavior be?
>>> We have these options:
>>>
>>> D1. By default, exceptions don't effect the current transaction.
>>> D2. By default, exceptions cause the current transaction to be
>>> marked for rollback.
>>> D3. By default, runtime exceptions cause the current transaction to be
>>> marked for rollback; checked exceptions do not effect the current
>>> transaction.
>>>
>>> After deciding on the default behavior, we have these choices for
>>> overriding the default:
>>>
>>> S1. You can't override the default.
>>> S2a. You can override the default by annotating exceptions that
>>> should cause rollback. (E.g., with @ApplicationException)
>>> S2b. You can override the default by annotating exceptions that
>>> should not cause rollback.
>>> S2c. You can override the default by annotating exceptions that
>>> should cause rollback and by annotating exceptions that should
>>> not cause rollback. (E.g., with a "rollback" element in
>>> @ApplicationException)
>>> S3a. You can override the default by annotating class or methods
>>> with a list of exceptions that should cause rollback.
>>> S3b. You can override the default by annotating class or methods
>>> with a list of exceptions that should not cause rollback.
>>> S3c. You can override the default by annotating class or methods
>>> with a list of exceptions that should cause rollback, and a
>>> list of exceptions that should not cause rollback.
>>>
>>> The S2c and S3c options have these additional options:
>>>
>>> A1. The rollback behavior is an element(s) of the base annotation.
>>> A2. The rollback behavior is a separate annotation(s).
>>>
>>> (Note that S2 and S3 are not mutually exclusive.)
>>>
>>> In all cases, the behavior for a given exception is determined by
>>> looking for an annotation or specification for that particular
>>> exception and if none is found traversing the superclass chain.
>>> That is, the exception behavior is always "inherited".
>>>
>>>
>>> My understanding is that Spring supports D3 S3c A1.
>>> (In addition, Spring allows specifying the exceptions as either
>>> Class objects or String names, which seems like overkill.)
>>>
>>> EJB supports D3 S2c A1 for local beans.
>>>
>>> I believe Reza was suggesting D3 S2c S3c A1.
>>>
>>> I believe David was suggesting D1 S3a A2.
>>
>> Thanks,
>> Jim Knutson
>> WebSphere Java EE Architect
>>
>>
>
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.1913 / Virus Database: 2112/4815 - Release Date: 02/17/12
>
>