Scott Marlow commented on CDI-162:
The extended persistence context (EntityManager) could be serializable. If the extended
persistence context is not serializable the stateful bean will not be serializable as
well. I'm not sure if this helps [with the concern raised
From EJB3 core:
4.2 Conversational State of a Stateful Session Bean
The conversational state of a stateful session object is defined as the session bean
instance’s field values, its associated interceptors and their instance field values, plus
the transitive closure of the objects from these instances’ fields reached by following
Java object references.
To efficiently manage the size of its working set, a session bean container may need to
temporarily transfer the state of an idle stateful session bean instance to some form of
secondary storage. The transfer from the working set to secondary storage is called
instance passivation. The transfer back is called activation.
In advanced cases, a session object’s conversational state may contain open resources,
such as open sockets and open database cursors. A container cannot retain such open
resources when a session bean instance is passivated. A developer of a stateful session
bean must close and open the resources in the
A container may only passivate a stateful session bean instance when the instance is not
in a transaction.
A container must not passivate a stateful session bean with an extended persistence
context unless the following conditions are met:
* All the entities in the persistence context are serializable.
* The EntityManager is serializable.
A stateless session bean is never passivated.
 PrePassivate and PostActivate lifecycle callback interceptor methods.
 The container is not permitted to destroy a stateful session bean instance because it
does not meet these requirements.
What I mean concretely about the top level component, is as follows. The extended
persistence context is created at the time that a stateful bean is created (injection or
jndi lookup) and that stateful bean is the "top most" stateful bean. When the
"top most" stateful bean, injects or lookups another stateful bean that also has
the same named extended persistence context, the additional bean inherits the extended
For the concrete example, please consider two cases, where the managed bean is the top
most bean that has looked up a stateful session bean. I'm not quite sure what it
would mean for the stateful session bean instance to be passivated (since the top most
managed bean will still reference the persistence context (keeping the xpc pinned in
memory). Even worse, would be if we are clustering and we failover the stateful session
bean to another cluster node. I think for both of these respective cases, the managed
bean would need to also be passivated or failed over to the same cluster node as the
Does this make any sense?
Support Extended Persistence Contexts in Managed beans
Project: CDI Specification Issues
Issue Type: Tracker
Affects Versions: 1.0
Reporter: Pete Muir
Fix For: 1.1 (Proposed)
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira