JNDI provides basic support for connection pooling through the use of the "com.sun.jndi.ldap.connect.pool" property (although it is not clear whether this property is available in non-Sun Java implementations). If this property is set to "true" in the environment properties when creating a context, then the JNDI implementation will create a connection pool that will create connections as needed, but return connections from the pool when they are available. There is virtually no control over the properties of the connection pool, nor is it possible to have multiple connection pools within the same JVM instance. While it is relatively nice that JNDI connection pooling is largely transparent to the client, it requires that clients be designed with a relatively poor pattern of closing connections after each sequence of operations, which will return them to the pool if there is one, but can easily lead to the unintended behavior of repeatedly creating and tearing down connections.
The Netscape Directory SDK for Java provides basic connection pooling support through the netscape.ldap.util.ConnectionPool class. Connections are checked out from the pool using the getConnection method, which may block if the pool does not have any available connections. Connections are returned to the pool by calling the rather unintuitive close method. It requires clients to be developed with explicit knowledge of and interaction with the connection pool, and it does not provide any capability for performing operations within the context of the pool itself.
The UnboundID LDAP SDK for Java provides an enhanced connection pooling mechanism that provides many of the good aspects of the JNDI and Netscape implementations without the negatives, and also provides additional functionality. The connection pooling implementation provided by the UnboundID LDAP SDK for Java has the following properties:
The UnboundID LDAP SDK for Java also offers a second connection pool implementation that provides the ability to define separate servers (or sets of servers) for read and write operations. With this read-write connection pool, one set of connections will be established for write operations like add, delete, modify, and modify DN operations, and another set of connections (potentially established to a different set of servers) will be used for read operations like search, bind, and compare operations. This can be useful for environments containing a number of read-only replicas that cannot accept write operations.