Creating (new Object()) and destroying (Garbage Collection) Java objects is expensive. If 10,000 users connect, making 10,000 objects will crash the server. How can EJB handle many clients efficiently?
Instance pooling is an optimization where the EJB container maintains a pool of ready-to-use bean instances. Instead of creating new objects per request, the container assigns an idle bean from the pool. After use, the bean is cleared of client data and returned to the pool.
- Container pre-creates a “pool” of bean instances in memory
- Client request arrives → container checks for free bean in pool
- If free bean exists → assign to client, execute method
- After execution → strip client-specific data, return bean to pool
- If pool exhausted → container may create new bean or wait
- If too many idle beans → container destroys some to free memory
Client Think Time: Humans take time between clicks (reading pages). During this time, the bean can serve other clients—huge memory savings.
- Memory conservation: Serve 10,000 clients with 50-100 beans
- High performance: Pre-created beans skip initialization phase
- Better GC: Fewer objects created/destroyed, less GC overhead
- Resource sharing: Also pools DB connections and sockets
- Client think time: Humans read pages, freeing beans for others
- Applies to: Stateless session beans, entity beans (not stateful)
- Built from: Stateless Session Bean, EJB Container
- Built from: Resource Pooling — broader concept including DB connections
- Builds into: Entity Bean — entity beans also pooled
- Related: getPrimaryKey(), Entity Context
- Related: Client Think Time — key enabler of pooling efficiency
- Stateful session beans: Cannot be pooled (each has dedicated client state)
- Pool size: Container-specific configuration; too small = wait, too large = waste
- State clearing: Container must strip client data before returning to pool
- Crash: Server crashes bypass normal pool return—may lose state
- Database connections: Also pooled separately from bean instances