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