Tips for Developing efficient LDAP Applications

I took this topic from sun blog but added some example code to show what the topic means so part of credit goes to them.

* Make sure to use LDAPv3 rather than LDAPv2. Some APIs still default to LDAPv2, but LDAPv2 doesn't support features like controls, extended operations, referrals, SASL authentication, and multiple binds on the same connection.

* Use at least minimal caching to avoid repeating the same queries. If you include a list of attributes to return, then make sure that you include all attributes you may need rather than performing different queries to retrieve the same entry with different attribute lists.

For example :

use this
String RETURN_ATTRIBUTES[] = { "mail","givenname","sn" };
Attributes attrs = ctx.getAttributes(DN, RETURN_ATTRIBUTES);
insted of

String RETURN_ATTRIBUTES[] = { "mail","givenname","mail" };
Attributes attrs = ctx.getAttributes(DN, RETURN_ATTRIBUTES);

String RETURN_ATTRIBUTES[] = { "mail","givenname","sn" };
Attributes attrs1 = ctx.getAttributes(DN, RETURN_ATTRIBUTES);

String RETURN_ATTRIBUTES[] = { "mail","givenname","givenname" };
Attributes attrs2 = ctx.getAttributes(DN, RETURN_ATTRIBUTES);


* Design your application to allow for loose consistency in replication and the possibility that reads and writes may happen on different systems without the application's knowledge. Avoid read-after-write behavior because it can have inconsistent results.

What I understood : In a load balanced environment when application uses connection pooling it may get connections from different servers. Some times if write operation is performed on the consumer, it may redirect the request to the master. Master may take some time to replicate the change to all consumers. If you try to do read after write there may be some inconsistencies.

* Don't treat the Directory Server like a relational database. Avoid splitting data into separate pieces so that you need to retrieve multiple entries to get all the information about a given entity.

* If you generate search filters, then do so intelligently. If you have compound filters, then use a form like "(&(a=b)(c=d)(e=f))" rather than "(&(&(&(a=b))(c=d))(e=f))" to avoid unnecessary nesting.

Unnecessary nesting may make the filter more complicated to understand and take more time to perform the operation as in the above case LDAP server will have to process 3 AND operators in the second query instead of 1 AND in the smart query. Softerra browser has a very good interface for building queries.

* Unbind connections when they're no longer needed. It's generally best to re-use connections as much as possible, but whenever you're done with a connection make sure it gets closed.

* Don't litter your code with hard-coded attribute/objectclass names, base DNs, server addresses/ports, usernames/passwords, etc. If you need to change something later, it can be hard to make sure that everything gets updated properly. You should centralize all such values in a constants class or a properties file so that they are simple to change if necessary.

* Where possible, maintain a set of persistent connections to the server (i.e., connection pools) rather than connecting and disconnecting for each operation. This will be much more efficient, especially when using SSL. In order to avoid leaking connections and duplicating large amounts of code, it may be a good idea to code the various types of operations into the connection pool itself so that those operations will check out a connection, perform the operation and any necessary error handling, and make sure the connection is put back into the pool.

I promise I will add a topic to explain how to write code for connection pooling in LDAP.

* Design your application to be able to handle the different kinds of failures that may arise: server down, network outage, DS backlogged or unresponsive, DS returning unexpected responses (e.g., unavailable or busy). Don't assume that a lost connection means the server is down -- it could be that the connection was closed due to the idle timeout or some other constraint.

Technorati : Efficient LDAP programming