RE: connection pooling in back-ldap?

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: Lawrence Greenfield [mailto:leg+@andrew.cmu.edu]

>    From: "Howard Chu" <hyc@highlandsun.com>
>    Date: Mon, 14 Oct 2002 11:28:55 -0700
> [...]
>    Just a note - this is actually a fairly intensive project,
> because it
>    requires additional multi-threading support in libldap_r
> that hasn't been
>    implemented yet. Specifically, pooling multiple incoming
> operations onto a
>    single LDAP session requires libldap_r to allow a single
> LDAP session to be
>    used by any number of threads concurrently. At present,
> this capability
>    doesn't exist. You might get around this using mutexes in
> back-ldap to
>    protect each access to an LDAP session, but I haven't
> looked into it.
>
> It probably makes more sense to do this outside of libldap_r.
>
> back-ldap could maintain a list of LDAP connections, each with an
> associated mutex. When a request comes in, the servicing thread calls
> pthread_mutex_trylock() on each current connection, and if it succeeds
> uses that connection (possibly refreshing it if has closed).

Yes, that's what I had in mind.

> If there are no available connections, it grabs a connection creation
> lock and adds a new connection to the list.

The existing connection logic looks for an LDAP connection associated with
the current slapd connection. This can be changed to match LDAP sessions with
the operation's op->o_ndn. However, the back-ldap Bind function needs some
special handling. Assuming that incoming requests bind with valid
DNs/credentials as opposed to anonymously, you can't just re-use an existing
LDAP session:
	op->o_ndn will be empty during a Bind; you must take care not to associate
this operation with any existing anonymously-bound sessions because obviously
after the Bind succeeds the session will no longer be anonymous.
	Furthermore, you cannot associate this operation with an existing session
using the same DN, because if the Bind fails (due to incorrect credentials,
etc.) then the existing session will be left in anonymous state.
	And of course, slapd abandons all existing operations whenever it receives a
Bind request on a connection, so you really can't issue a second Bind on an
existing session without interfering with other operations relying on that
session.

So in the general case, when clients bind to back-ldap with valid
credentials, you need to create a separate LDAP session for each Bind
operation. After it succeeds, you can close the connection and use your
pooled connection if you wish, but I somehow think this hasn't saved you a
whole lot, performance-wise. (I suppose it saves on the long-term number of
outstanding connections that a server maintains.)

If the incoming bind is anonymous, and you already have an existing anonymous
session handle, then you can just ignore the Bind request and re-use the
existing session directly.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support