How long does a session bean live? Is it days? Years? Can it survive a server crash? Understanding bean lifetime is crucial for deciding what data to store in a session bean vs a database.
Session beans are short-lived, non-persistent objects. Their lifetime is roughly the duration of the client session—when the client disconnects or times out, the container may destroy the bean. Session beans live in RAM and do NOT survive server crashes.
Contrast with Entity Beans which can live for months/years (persistent in database).
- Client session starts: Client calls
create()on home interface → container creates bean - During session: Bean serves the client (could be milliseconds or hours)
- Client disconnects: Bean is destroyed (or returned to pool for stateless)
- Server crashes: ALL session beans are lost (in-memory only)
- Timeout: If client is idle too long, container destroys bean
- Non-persistent: Session beans are NOT saved to permanent storage
- Client-scoped: Lifetime tied to client session (not permanent)
- Container-managed: Container decides exactly when to destroy
- RAM-only: Live in memory, not on disk
- Built from: Session Bean, EJB Container (manages lifetime)
- Builds into: Stateful Session Bean (dedicated lifetime), Stateless Session Bean (pool-based lifetime)
- Contrasts with: Entity Bean (persistent, survives crashes, lives for years)
- Related: Passivation (stateful beans may be temporarily stored to disk)
- Don’t store critical data in session beans: If server crashes, it’s gone
- Stateless beans may be destroyed after EVERY method call: Don’t expect data to persist between calls
- Timeout values are configurable: Deployer sets session timeout in vendor-specific config