Note that it is NOT normal to be able to bind an around-invoke interceptor to a lifecycle callback on a target class. This would be non-standard functionality for the @Transactional interceptor.
On 11 Mar 2013, at 17: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.