I have a weak preference for Option #1 on the grounds that its the most
likely useful default for @PostConstruct and is more flexible than #4. #4
is my least favourite because it implies a rather ugly mix of container
managed and bean managed transactions.
#2 and #3 are also reasonable.
Regards,
Ian
From: Paul Parkinson <paul.parkinson_at_oracle.com>
To: users_at_jta-spec.java.net,
Cc: Marina Vatkina <marina.vatkina_at_oracle.com>, Bill Shannon
<bill.shannon_at_oracle.com>, Linda DeMichiel <linda.demichiel_at_oracle.com>
Date: 11/03/2013 17:41
Subject: [jta-spec users] Fwd: [javaee-spec users] [jsr342-experts]
transactional interceptors and lifecycle methods
Hello,
Note the open issue related to the @Transactional interceptors and the
@PostConstruct method.
Please let us know which choice you prefer before Friday, March 15.
Thanks,
Paul
Begin forwarded message:
From: Bill Shannon <bill.shannon_at_oracle.com>
Subject: [javaee-spec users] [jsr342-experts] transactional interceptors
and lifecycle methods
Date: March 11, 2013 1:35:57 PM EDT
To: jsr342-experts_at_javaee-spec.java.net
Reply-To: jsr342-experts_at_javaee-spec.java.net
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.
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU