RE: Pooling connections in back-ldap/meta

["Howard Chu" <hyc@highlandsun.com>]

It sounds like your approach may work, assuming you get the locking right,
and assuming libldap's cache support actually works (sounds like it
doesn't...). I think you still need a separate cache per BindDN, to deal with
access controls. And Pierangelo has already pointed out the ITS with a
different caching approach.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

> -----Original Message-----
> From: owner-openldap-devel@OpenLDAP.org
> [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Stephen Brandon
> Sent: Sunday, November 10, 2002 7:15 AM
> To: OpenLDAP-devel@OpenLDAP.org
> Subject: 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.
>
> Cheers,
> Stephen Brandon
> Brandon IT Consulting
>
>