Error in EJB 3.0 core specification?

[Vahan Harput]

Hi all,

I have a question regarding the allowed operations in the lifecycle callback methods of stateful session beans:

On the page 80/81 of the EJB 3.0 core specification, it is specified that the PostConstruct/PreDestroy/PrePassivate/PostActivate lifecycle callback methods run in an unspecified transaction and security context. It is also specified that in such methods it is not allowed to access resource managers and other enterprise beans.

At the same time however, in the table 1 of page 79 accessing resource managers and enterprise beans is allowed for these lifecycle callback methods.

This seems to be a contradiction. Is this an error in the specification or am I missing something?

Best regards

[Camilo Morales]

Originally posted by Vahan Harput:
Hi all,

I have a question regarding the allowed operations in the lifecycle callback methods of stateful session beans:

On the page 80/81 of the EJB 3.0 core specification, it is specified that the PostConstruct/PreDestroy/PrePassivate/PostActivate lifecycle callback methods run in an unspecified transaction and security context. It is also specified that in such methods it is not allowed to access resource managers and other enterprise beans.

At the same time however, in the table 1 of page 79 accessing resource managers and enterprise beans is allowed for these lifecycle callback methods.

This seems to be a contradiction. Is this an error in the specification or am I missing something?

Best regards

Hey,

I can't find where does the spec say that methods with an unspecified transaction and security context can not acces resource managers. In page 350, regarding "13.6.5 Handling of Methods that Run with �an unspecified transaction context�", the spec say this:

The EJB specification does not prescribe how the container should manage the execution of a method with an unspecified transaction context�the transaction semantics are left to the container implementation.
Some techniques for how the container may choose to implement the execution of a method with an unspecified transaction context are as follows (the list is not inclusive of all possible strategies):

� The container may execute the method and access the underlying resource managers without a transaction context.
� The container may treat each call of an instance to a resource manager as a single transaction (e.g. the container may set the auto-commit option on a JDBC connection).
� The container may merge multiple calls of an instance to a resource manager into a single transaction.
� The container may merge multiple calls of an instance to multiple resource managers into a single transaction.
� If an instance invokes methods on other enterprise beans, and the invoked methods are also designated to run with an unspecified transaction context, the container may merge the resource manager calls from the multiple instances into a single transaction.
� Any combination of the above.

For what I know, lifecycle methods like PostConstruct/PreDestroy/PrePassivate/PostActivate (specially PrePassivate/PostActivate) are intended specially to give the Bean Provider the oportunity to close/re-open any resource connections opened manually at any time of the Bean lifetime. So, it wouldn't make any sense if these methods couldnt access resource managers, because you must have access in order to close-re-open the connections.

Please correct me if I'm wrong,

Regards,

[Vahan Harput]

Hi Camilo,

I can't find where does the spec say that methods with an unspecified transaction and security context can not acces resource managers.

Thanks for your reply. Here the quote regarding the access to resource managers and transaction/security context from page 81:

"Accessing resource managers and enterprise beans is disallowed in the session bean methods for which the container does not have a meaningful transaction context and/or client security context."

Best regards