<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Bill Shannon asked me to forward
<pre wrap=""><a class="moz-txt-link-freetext" href="http://java.net/projects/javaee-spec/lists/jsr342-experts/archive/2013-03/message/7">http://java.net/projects/javaee-spec/lists/jsr342-experts/archive/2013-03/message/7</a></pre>
to the EG. I have pasted it here. I will forward any feedback to
Bill<br>
<br>
<h2 class="pageTitle">[jsr342-experts] transactional interceptors
and lifecycle methods</h2>
<br>
We recently discovered an issue with the interaction between the<br>
new @Transactional interceptors and the @PostConstruct method.<br>
Should @PostContruct (and @PreDestroy) methods be transactional,<br>
and if so how should the transaction type be controlled?<br>
<br>
We'd like your feedback on this issue before Friday, March 15.<br>
<br>
We've come up with four options for how this could work:<br>
<br>
1. @PostConstruct is not transactional by default, but @Transactional<br>
is allowed.<br>
<br>
@Transactional(MANDATORY)<br>
public class MyBean {<br>
@PostConstruct<br>
public void postConstruct() {<br>
// run with no transaction<br>
}<br>
<br>
public void myMethod() {<br>
// uses @Transactional(MANDATORY)<br>
}<br>
}<br>
<br>
@Transactional(MANDATORY)<br>
public class MyOtherBean {<br>
@PostConstruct<br>
@Transactional(REQUIRES_NEW)<br>
public void postConstruct() {<br>
// run with a new transaction<br>
}<br>
<br>
public void myMethod() {<br>
// uses @Transactional(MANDATORY)<br>
}<br>
}<br>
<br>
2. @PostConstruct is like any other method and inherits the class-level<br>
transaction attribute, but the developer must override the class-level<br>
attribute in some cases.<br>
<br>
@Transactional(MANDATORY)<br>
public class MyBean {<br>
@PostConstruct<br>
public void postConstruct() {<br>
// FAILS because there can be no existing transaction context<br>
}<br>
<br>
public void myMethod() {<br>
// uses @Transactional(MANDATORY)<br>
}<br>
}<br>
<br>
@Transactional(MANDATORY)<br>
public class MyOtherBean {<br>
@PostConstruct<br>
@Transactional(REQUIRES_NEW)<br>
public void postConstruct() {<br>
// run with a new transaction<br>
}<br>
<br>
public void myMethod() {<br>
// uses @Transactional(MANDATORY)<br>
}<br>
}<br>
<br>
3. @PostConstruct is like any other method and inherits the class-level<br>
transaction attribute, but methods (like lifecycle callbacks) for<br>
which there can be no preexisting transaction context are handled as<br>
if they were REQUIRES_NEW when the MANDATORY attribute is specified<br>
(i.e., the attribute value handling here is special-cased).<br>
<br>
@Transactional(MANDATORY)<br>
public class MyBean {<br>
@PostConstruct<br>
public void postConstruct() {<br>
// runs with a new transaction<br>
}<br>
<br>
public void myMethod() {<br>
// uses @Transactional(MANDATORY)<br>
}<br>
}<br>
<br>
@Transactional(MANDATORY)<br>
public class MyOtherBean {<br>
@PostConstruct<br>
@Transactional(REQUIRES_NEW)<br>
public void postConstruct() {<br>
// run with a new transaction, same as above<br>
}<br>
<br>
public void myMethod() {<br>
// uses @Transactional(MANDATORY)<br>
}<br>
}<br>
<br>
4. @PostConstruct can never be transactional. UserTransaction can be<br>
used explicitly in the @PostConstruct method if needed.<br>
<br>
@Transactional(MANDATORY)<br>
public class MyBean {<br>
@PostConstruct<br>
public void postConstruct() {<br>
// runs with no transaction context<br>
}<br>
<br>
public void myMethod() {<br>
// uses @Transactional(MANDATORY)<br>
}<br>
}<br>
<br>
@Transactional(MANDATORY)<br>
public class MyOtherBean {<br>
@PostConstruct<br>
@Transactional(REQUIRES_NEW)<br>
public void postConstruct() {<br>
// @Transactional is either ignored or causes runtime failure<br>
}<br>
<br>
public void myMethod() {<br>
// uses @Transactional(MANDATORY)<br>
}<br>
}<br>
<br>
<br>
#1 is most similar to stateful session beans in the current version of<br>
the EJB spec. When the ability to have transactional @PostConstruct<br>
methods on stateful session beans was added to the EJB spec, it<br>
couldn't be done by default due to compatibility.<br>
<br>
#3 is consistent with Singletons in the current version of the EJB spec.<br>
<br>
#4 is most similar to previous versions of the EJB spec.<br>
<br>
We're currently leaning towards #3, since it seems consistent with other<br>
interceptor use, but good arguments can be made for any of these choices.<br>
We really need your feedback.<br>
<br>
Let us know which choice you prefer before Friday, March 15.<br>
<br>
<br>
</body>
</html>