How does the EJB container manage memory when there are many stateful session beans, each holding client state?
Passivation is the process where the container serializes a stateful session bean to secondary storage (typically disk) to free up memory. The bean moves from “Ready” state to “Passive” state.
- Container invokes ejbPassivate() callback on the bean
- Bean should release resources and prepare for serialization
- Serialized state saved to persistent storage
- Bean instance removed from memory
- When client calls a method on the passivated bean, container activates it
- Only applies to stateful session beans
- Triggered when container’s active instance limit is reached
- Preserves conversational state across the transition
- Opposite of activation
- Built from: Stateful Session Bean
- Builds into: Activation
- Contrasts with: ejbRemove()
- Related: ejbPassivate() callback
- Resources like database connections should be released before passivation
- Don’t rely on ejbPassivate() for critical cleanup either
- Performance impact when activation occurs