Discussions

EJB design: Searching LDAP White Pages through JNDI

  1. Searching LDAP White Pages through JNDI (2 messages)

    We are building an application to facilitate seaches of our LDAP White Pages catalog (through jndi). The structure we use is with a DAO and stateless session beans.
    The DAO creates a connection to the LDAP server with "new InitialDirContext(...)" and then a normal search operation is done. Many times we use multi-level searches
    and this generates lots and lots of InitialDirContexts and connections. The result is that our LDAP-server (iPlanet) is overwhelmed.

    Now, the normal way to use jndi is to create new contexts from the initial one with the lookup()-method. However, the stateless session bean makes this impossible
    because we can't keep a reference to the initial dir context.

    What I would like to know is, what method should we use to keep this reference?
    The context mustn't be shared between sessions, and preferrably the connection shouldn't be kept open for too long either. My idea is that we could keep this reference during a page load (HTTP request) and then throw it away.

    Any suggestions?
  2. Use the Sun connection pool to avoid opening loads of connections for the same environment properties.

    http://java.sun.com/products/jndi/tutorial/ldap/connect/pool.html

    Or you can do your own connection pool (very easy, just use jakarta commons pool) you will have lots more settings, it's actually more interesting if you have per user ldap connection (authentication) and because your search must take into account user roles as well as you can also validate a connection when you take it from the pool. It allows you to dedicate one connection per user (you can assign it to the current thread during the request duration with a servlet filter for instance) and make sure that each time you get it, you are obtaining a valid connection and not a stalled one

    http://jakarta.apache.org/commons/pool/
  3. We are using a connection pool[ Go to top ]

    and it helps a bit, but the program still uses far too many connections. We can of course limit the pool to very few connections, 50 say, but then the applicaton hangs.

    Without a limit it grows to over 1000, sometimes over 2000 connections during low volume testing, maybe 2-3 users.

    One search result page can use up more han 100 connections sometimes and this in my view clearly indicates that something is wrong.

    Thanks for the suggestion anyway!