[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
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
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.
Brandon IT Consulting