From: Werner Keil <werner.keil_at_gmail.com>
Date: Tue, 12 Mar 2013 11:00:25 +0100

+1

I would say #1 looks more consistent and easier to control transactions.
Knowing this can be a beast of its own, e.g. transactions (there with
Spring, which made the thing even a bit more complicated[?]) and the
side-effects different components and beans had on each other were the
biggest challenge to that big Indian project 2 years ago.

Werner

On Tue, Mar 12, 2013 at 10:36 AM, Markus Eisele <myfear_at_web.de> wrote:

> Hi Bill,
>
> I am unsure if I like #1 or #3 the most. I tend to #1 because it
> somehow behaves a little more like I would have expected it to be.
> In #3 if I do nothing I always end up with a transaction .. so #1 is
> better .. no annotation .. no transaction ...
>
> Thanks
> - M
>
> On 11 March 2013 18:35, Bill Shannon <bill.shannon_at_oracle.com> wrote:
> > We recently discovered an issue with the interaction between the
> > new @Transactional interceptors and the @PostConstruct method.
> > Should @PostContruct (and @PreDestroy) methods be transactional,
> > and if so how should the transaction type be controlled?
> >
> > We'd like your feedback on this issue before Friday, March 15.
> >
> > We've come up with four options for how this could work:
> >
> > 1. @PostConstruct is not transactional by default, but @Transactional
> > is allowed.
> >
> > @Transactional(MANDATORY)
> > public class MyBean {
> > @PostConstruct
> > public void postConstruct() {
> > // run with no transaction
> > }
> >
> > public void myMethod() {
> > // uses @Transactional(MANDATORY)
> > }
> > }
> >
> > @Transactional(MANDATORY)
> > public class MyOtherBean {
> > @PostConstruct
> > @Transactional(REQUIRES_NEW)
> > public void postConstruct() {
> > // run with a new transaction
> > }
> >
> > public void myMethod() {
> > // uses @Transactional(MANDATORY)
> > }
> > }
> >
> > 2. @PostConstruct is like any other method and inherits the class-level
> > transaction attribute, but the developer must override the class-level
> > attribute in some cases.
> >
> > @Transactional(MANDATORY)
> > public class MyBean {
> > @PostConstruct
> > public void postConstruct() {
> > // FAILS because there can be no existing transaction
> context
> > }
> >
> > public void myMethod() {
> > // uses @Transactional(MANDATORY)
> > }
> > }
> >
> > @Transactional(MANDATORY)
> > public class MyOtherBean {
> > @PostConstruct
> > @Transactional(REQUIRES_NEW)
> > public void postConstruct() {
> > // run with a new transaction
> > }
> >
> > public void myMethod() {
> > // uses @Transactional(MANDATORY)
> > }
> > }
> >
> > 3. @PostConstruct is like any other method and inherits the class-level
> > transaction attribute, but methods (like lifecycle callbacks) for
> > which there can be no preexisting transaction context are handled as
> > if they were REQUIRES_NEW when the MANDATORY attribute is specified
> > (i.e., the attribute value handling here is special-cased).
> >
> > @Transactional(MANDATORY)
> > public class MyBean {
> > @PostConstruct
> > public void postConstruct() {
> > // runs with a new transaction
> > }
> >
> > public void myMethod() {
> > // uses @Transactional(MANDATORY)
> > }
> > }
> >
> > @Transactional(MANDATORY)
> > public class MyOtherBean {
> > @PostConstruct
> > @Transactional(REQUIRES_NEW)
> > public void postConstruct() {
> > // run with a new transaction, same as above
> > }
> >
> > public void myMethod() {
> > // uses @Transactional(MANDATORY)
> > }
> > }
> >
> > 4. @PostConstruct can never be transactional. UserTransaction can be
> > used explicitly in the @PostConstruct method if needed.
> >
> > @Transactional(MANDATORY)
> > public class MyBean {
> > @PostConstruct
> > public void postConstruct() {
> > // runs with no transaction context
> > }
> >
> > public void myMethod() {
> > // uses @Transactional(MANDATORY)
> > }
> > }
> >
> > @Transactional(MANDATORY)
> > public class MyOtherBean {
> > @PostConstruct
> > @Transactional(REQUIRES_NEW)
> > public void postConstruct() {
> > // @Transactional is either ignored or causes runtime
> failure
> > }
> >
> > public void myMethod() {
> > // uses @Transactional(MANDATORY)
> > }
> > }
> >
> >
> > #1 is most similar to stateful session beans in the current version of
> > the EJB spec. When the ability to have transactional @PostConstruct
> > methods on stateful session beans was added to the EJB spec, it
> > couldn't be done by default due to compatibility.
> >
> > #3 is consistent with Singletons in the current version of the EJB spec.
> >
> > #4 is most similar to previous versions of the EJB spec.
> >
> > We're currently leaning towards #3, since it seems consistent with other
> > interceptor use, but good arguments can be made for any of these choices.
> > We really need your feedback.
> >
> > Let us know which choice you prefer before Friday, March 15.
> >
> > Thanks.
>