[cdi-dev] [JBoss JIRA] (CDI-162) Support Extended Persistence Contexts in Managed beans

[ https://issues.jboss.org/browse/CDI-162?page=com.atlassian.jira.plugin.sy... ] 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 here|https://struberg.wordpress.com/2012/04/25/is-there-a-way-to-fix-the-...]. {quote} 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:[9] * All the entities in the persistence context are serializable. * The EntityManager is serializable. A stateless session bean is never passivated. [8] PrePassivate and PostActivate lifecycle callback interceptor methods. [9] The container is not permitted to destroy a stateful session bean instance because it does not meet these requirements. {quote} 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 persistence context. 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 stateful bean. Does this make any sense? -- 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