jsr342-experts@javaee-spec.java.net

[jsr342-experts] Re: transactional methods and exceptions

From: Jim Knutson <knutson_at_us.ibm.com>
Date: Fri, 17 Feb 2012 17:26:29 -0600

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