LDAP SDK for Java

Improved Connection Pooling

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:

• It is possible to have multiple distinct connection pools in use by the same application or different applications within the same JVM.
  
  
• It is possible to explicitly check out and release connections.
  
  
• It is possible to lazily create connections as needed.
  
  
• It is possible to indicate that a connection may have become invalidated when releasing a connection to indicate that it should no longer be used by the pool.
  
  
• It is possible to configure the connection pooling to specify whether it should block if no connections are available and if so for how long. It is also possible to configure whether it should attempt to create a new connection if none are available.
  
  
• It provides support for processing operations within the context of the pool, so processing those operations will automatically check out and return the connection and perform all necessary error handling, without requiring the client developer to concern themselves with those details.
  
  
• It provides a method for processing multiple operations over the same pooled connection without the need for the caller to perform the necessary connection management or error handling.
  
  
• It implements the same LDAPInterface interface as the LDAPConnection class. This means that clients can be developed to use LDAPInterface objects instead of LDAPConnection objects in cases where it doesn't matter if the operation is performed on an individual connection or a pooled connection.
  
  
• It works in conjunction with the Support for Failover and Load Balancing so that the pool can contain connections to multiple servers, allowing the load to be spread between them.
  
  

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.