[jsr342-experts] Re: transactional methods and exceptions
- From: "Deepak Anupalli" <deepak@...>
- To: <jsr342-experts@...>
- Subject: [jsr342-experts] Re: transactional methods and exceptions
- Date: Tue, 31 Jan 2012 12:06:56 +0530
That was a pretty neat breakup of the possible options.
I would prefer these options
D3 - same as the EJB model
S2b - overrides can be specified for rollback behaviour of "system
S3c - overrides can be specified based on the invocation context, also
A2 - annotations are required to specify rollback behaviour alone
However, I'm a bit skeptic about the @ApplicationException which is in use
in the EJB context and may be forced to consider S2c.
I wish we could consider D1 S3a, but a great deal of backward compatibility
issues need to be tackled.
From: Bill Shannon [mailto:bill.shannon@...]
Sent: 31 January 2012 02:10
Subject: [jsr342-experts] transactional methods and exceptions
One of the issues with the new transactional annotations we're proposing is
how to handle exceptions that are thrown out of a transactional method.
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
After deciding on the default behavior, we have these choices for overriding
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
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.
Our goal with these new transactional annotations was to come up with
something that was simple, where "simple" means both "has few concepts" and
"is easily understood by developers". In addition to being simple, it needs
to satisfy a large percentage of the use cases.
The simplest is D1 S1, but I don't think that matches what developers will
Given the prevalence of D3 in existing systems, D3 S1 would be very simple.
Unfortunately, we're told that many developers are moving towards using
runtime exceptions for everything, so D3 S2b would be a relatively simple
The major advantage I see for the S3 options is that they allow you to more
easily override the default behavior for "system" exceptions.
For example, if your method throws IllegalArgumentException in a case where
it knows that it hasn't modified the state of the transaction, you might
like that exception to *not* cause the transaction to be marked for
rollback. With S2, you would have to subclass the exception and mark the
subclass. But of course that does have the advantage that other uses of
that exception in methods you call have the default behavior.
Which options do you prefer?