[Date Prev][Date Next] [Chronological] [Thread] [Top]

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
> (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


and the resulting huge thread.


Pierangelo Masarati