IdP use of LDAP and connection pooling

Chad La Joie lajoie at
Thu Sep 8 19:49:41 BST 2011

Well, there are various reasons you might pool connections, of course:
  - because the connections are expensive to establish
  - because you know you'll be doing a number calls in succession
  - as a way to "reserve" resources on the server

LDAP calls aren't any worse to establish than connections to a
database; one round trip in most cases, more if you're using StartTLS.
 So that's not really an issue.  You may want to "reserve" server
resources if your LDAP server is under heavy load.  So, for your case,
I'd say that you should use connection pooling for LDAP if you used
connection pooling for databases because of the number of rapid
successive calls.

The LDAP data connector does allow you to customize what exactly
happens when a connection is closed unbeknownst to the IdP.  The
default is to just retry, I believe.  I think the only time you'll
ever see a connection failure is if your servers are actually

In terms of the timeout, there are some LDAP control extensions that
would allow you to adjust the timeout (i.e., the client can tell the
server how long it would like the timeout to be) but as best as I know
AD does not support that.

On Thu, Sep 8, 2011 at 14:26, Cantor, Scott <cantor.2 at> wrote:
> Is there any conventional wisdom or experience with the use of connection
> pooling in the IdP data connectors for LDAP, and specifically AD?
> We're expanding use of LDAP as a data source, but my expertise lies
> heavily on the RDBMS side and how the pooling behaves there. I did some
> initial playing around adding a connection pool and am seeing what I kind
> of expected, which is constant LDAP connection resets when the pools
> validate when connections are idle.
> I'm just wondering these kinds of things:
> - are pools necessary to get reasonable performance on highly loaded IdPs?
> - do they handle failed connections reasonably without ever surfacing them
> as actual data connector failures?
> - are there ways to maintain connections and avoid the timeouts from the
> client end?
> - is pool validation even needed, or does it just retry on failures and
> handle things gracefully?
> I use LDAP as a secondary source right now, with no pooling yet, and it's
> basically fine, though I don't know the actual load on the AD servers.
> Last thing I want is to add pooling and have it cause failures (which
> poorly implemented RDBMS pools do cause).
> -- Scott
> --
> To unsubscribe from this list send an email to users-unsubscribe at

Chad La Joie
trusted identities, delivered

More information about the users mailing list