[Date Prev][Date Next]
Re: Pooling connections in back-ldap/meta
> 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
> 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
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
and the resulting huge thread.