33.2.2. Case #1: Surviving EJB passivation

Conversations were initially designed for stateful session beans because the EJB3 specification defines stateful session beans as the hosts of the extended persistence context. Seam introduces the Seam-managed persistence context, which works around a number of limitations in the specification. Both contexts can be used with stateful session beans.

For a stateful session bean to remain active, a client must hold a reference to the stateful session bean. Seam's conversation context is an ideal location for this reference, which means that the stateful session bean remains active for the duration of the conversation context. Further, EntityManagers that are injected into the stateful session bean with the @PersistenceContext(EXTENDED) annotation will be bound to the stateful session bean and remain active for the bean's lifetime. EntityManagers injected with the @In annotation are maintained by Seam and stored directly in the conversation context, so they remain active for the duration of the conversation, independent of the stateful session bean.

The Java EE container can also passivate a stateful session bean, but this method can be problematic. Rather than making the container responsible for this process, after each invocation of the stateful session bean, Seam transfers the reference to the entity instance from the stateful session bean to the current conversation, and therefore into the HTTP Session. This nullifies the associated fields on the stateful session bean. Seam then restores these references at the beginning of the subsequent invocation. Because Seam already stores the persistence manager in the conversation, stateful session bean passivation and activation has no adverse effect on the application.

You can disable passivation on stateful session beans. See the Ejb3DisableSfsbPassivation page on the JBoss Wiki for details.