Creating expensive resources like database connections, socket connections, or threads for each client request is inefficient. These resources take time to create and are limited. How can we reuse them efficiently?
Resource pooling is the practice of maintaining a pool of ready-to-use resources (DB connections, sockets, threads) that are shared across clients. When a client needs a resource, it’s taken from the pool; when done, it’s returned for reuse.
- Pool creation: Container pre-creates N connections (e.g., 50 DB connections)
- Client request: Client needs DB access → gets connection from pool
- Usage: Client uses connection for SQL operations
- Return: Connection returned to pool (not closed/destroyed)
- Reuse: Next client gets the same connection
JDBC drivers, JMS connection factories, and EJB instances all use pooling.
- Expensive resources: DB connections, sockets, threads are pooled
- Container-managed: EJB container manages resource pools
- Enormous efficiency: Same connection serves many clients
- Shared by beans: Entity beans, session beans share DB connection pool
- Configurable: Pool min/max size set in container config
- Built from: Instance Pooling — bean pooling is one type of resource pooling
- Builds into: JDBC — JDBC connections are pooled
- Related: JMS — JMS connections also pooled
- Related: EJB Container — container manages resource pools
- Leaked connections: Forgetting to close() returns connection to pool
- Pool exhaustion: All connections busy → clients wait or fail
- Transaction scope: Connection must remain same within transaction
- Pool sizing: Too small = wait; too large = waste memory