Details
-
Improvement
-
Status: Open
-
Major
-
Resolution: Unresolved
-
3.1, 3.1.1, 3.1.2
-
None
-
None
Description
Latest EJB 3.1 spec allows @TransactionAttribute on the PostConstruct/PreDestroy callbacks of @Singleton beans. Use of @TransactionAttribute on the PostConstruct/PreDestroy callbacks of any other bean type is still illegal.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
OpenEJB does not seem to apply transaction policies with @Singleton beans.
My feeling (after checking in the spec) is that we must deal with transaction policies for PostConstruct/PreDestroy lifecycle callback interceptor methods. Actually, it's not the case for @Singleton nor @Stateless whereas we do it for @Stateful.
4.3.14 Transaction Context of Session Bean Methods
The implementation of a method defined in a session bean's business interface or component interface or no-interface view, a web service method, timeout callback method, or singleton PostConstruct/PreDestroy lifecycle callback interceptor method, is invoked in the scope of a transaction determined by the transaction attribute specified in the bean's metadata annotations or deployment descriptor.
...
For example, it would be wrong to perform database operations within a stateful session bean's PostConstruct or PreDestroy lifecycle callback interceptor methods and to assume that the operations are part of the client's transaction. The PostConstruct and PreDestroy methods for stateful and stateless session beans are not controlled by a transaction attribute because handling rollbacks in these methods would greatly complicate the session instance's state diagram.
4.3.4 Session Bean Lifecycle Callback Interceptor Methods
The PostConstruct lifecycle callback interceptor methods for stateless and stateful session execute in an unspecified transaction context.
13.6 is also a good pointer.
So, from my understanding, we should manage transaction policies in lifecycle methods for @Singleton but not necessary for @MDB @Stateless and Stateful (an unspecified transaction context).
IMHO, we should add some consistency because the behavior for @Stateless and @Stateful is different (BTW, i didn't check for MDB).