Re: Pooling connections in back-ldap/meta

[Stephen Brandon <stephen@brandonitconsulting.co.uk>]

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.

Cheers,
Stephen Brandon
Brandon IT Consulting