Connection pool behavior

Elastic pool sizing

When the enhanced connection pool is active, the server allocates space for ibm-slapdDbMaxConnections connection slots at startup. However, it only initializes ibm-slapdDbMinConnections. Additional connections are created automatically when the existing active connections are fully utilized.

When a client operation needs a database connection and none are available, the pool checks whether the current connection count is below the maximum. If the current number of connections is below ibm-slapdDbMaxConnections, a new connection is created and assigned to the request. The new connection then becomes part of the pool and is available for future operations.

During idle periods, the background health check thread identifies connections that have been inactive longer than the configured TTL. If the current pool size is above the minimum, the idle connections are closed and removed from the pool. If the pool has reached the minimum size, the connections are re-established to maintain the minimum number of available connections.

Table 1. Pool size parameters
Parameter	Controls	Effect when too low	Effect when too high
`ibm-slapdDbMinConnections`	Startup and floor size of pool	Slower response until pool grows expands to handle increased workload.	Higher memory usage at startup and during idle periods.
`ibm-slapdDbMaxConnections`	Ceiling for on-demand pool growth	Thread wait events and increased latency under heavy load.	Higher peak database memory and connection overhead.

Connection hold time

When ibm-slapdDbConnectionHoldTime is greater than zero, a database connection is retained for a configured number of seconds after an LDAP operation completes instead of being returned immediately to the pool. If the same client sends another LDAP request within the configured hold time, the server reuses the held connection, bypassing the pool lock entirely.

This mechanism is most effective for clients that issue multiple LDAP operations in rapid succession, such as a bind followed by search or modify operations. For workloads with longer intervals between client requests, hold time provides less benefit and can be disabled by setting the value to 0.

Note: Connection hold time is automatically disabled during database transactions. During a transaction, the server uses the same database connection for all transactional operations until the transaction is committed or rolled back. The hold time mechanism does not interfere with transaction handling.

Table 2. Recommended Connection Hold Time Values
Workload pattern	Recommended hold time
Clients issue bind + 2–10 operations within 1–2 seconds	3 to 5 seconds (default)
Clients issue one operation and disconnect	0 (disabled)
High-concurrency environments with many simultaneous clients	1 to 3 seconds to balance reuse against connection starvation
Batch or bulk processing tools (`ldif2db`, `db2ldif`)	Not applicable, hold time is automatically disabled for command-line tools

Important: Setting a very high hold time such as, 60 seconds or more in environments with many concurrent clients can prevent connections from returning to the pool promptly, causing other threads to wait. Monitor the ibm-slapdDbConnectionPoolWaitEvents attribute to detect pool contention. For more information, see Monitoring and tuning the connection pool.

Background health check

A background maintenance thread runs periodically at the interval specified by ibm-slapdDbHealthCheckInterval. The thread only examines connections that are not currently in use by an LDAP operation. During each maintenance pass, it performs the following work:

Hold time expiration
Connections whose hold window has elapsed are returned to the available pool and any threads waiting for a connection are notified.
TTL expiration
Connections that have been idle longer than ibm-slapdDbConnectionTTL are recycled. If the pool is above the minimum size, the connection is closed and its slot is freed. If the pool is at or below the minimum, the connection is closed and immediately re-established so the minimum pool size is always maintained.
Connectivity validation
The thread tests each idle connection with a lightweight query. A connection that fails validation multiple times in succession is marked as unavailable and removed from the pool. A new connection is then created to replace it if the pool is below the minimum size.

Note: The background health check thread is started automatically when the server starts. It stops gracefully when the server shuts down. The thread is not started for command-line tools such as ldif2db, db2ldif, or idsrunstats, which use a single dedicated connection.