Re: Pooling connections in back-ldap/meta

["Pierangelo Masarati" <ando@sys-net.it>]

> To follow up my own message, it looks like ldapinfo is in fact global,
> so  that's not the problem.
>
> Tracking down the issue further, it seems that ldap_enable_cache and
> friends  only need the LDAP structure because that's where the cache is
> held  (ld->ld_cache).
>
> Pooling connections has not been working with back-ldap, because each
> new  connection creates a new LDAP structure, and also because the
> connection pool  drops info about a particular connection once it
> receives an UNBIND.
>
> For my own purposes, my customised version of back-ldap is going to
> simply  create a dummy LDAP struct for the purposes of holding a cache,
> and manually  call the various cache functions at appropriate moments
> (eg
> ldap_add_request_to_cache, ldap_add_result_to_cache etc). I'll have to
> put  locks around the various usages since it's going to end up being
> called from  several simultaeous threads.
>
> I'm not sure what a really elegant solution to this would be. Certainly
> there  would need to be locks built in to the caching routines in
> cache.c, but in  order to be used in back-meta where there is more that
> one external server  being queried, there would need to be a pool of
> caches, to hold one for each  server.
>
> I'd be interested to contribute to any ongoing discussion about this --
> but I  think I have a solution that's going to work for my immediate
> needs.

I'm not sure the ldap_*_cache() approach you're considering
is the best; I note that caching is considered experimental
and its use is deprecated. I suggest you have a look at the
patch contained in ITS#2062, which should being reviewed
by someone (I'd give it a look in a few days).  There was
some debate at the time it was submitted, so you may want to
read the message

http://www.openldap.org/lists/openldap-devel/200209/msg00013.html

and the resulting huge thread.

Pierangelo.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it