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

RE: Proxy cache extension for OpenLDAP



> -----Original Message-----
> From: Apurva Kumar [mailto:kapurva@in.ibm.com]

> Hi,
>
> Thanks for your suggestions on the proxy cache code.
>
> The suggestion to use callback facility to support all the backends without
> modifying their codes can save a lot of work. However I am trying to figure
> out how to do the following operations required in the cache with this
> facility.
>
> 1) adding an entry without a parent.
> 2) deleting an entry with children (without deleting the children).
> 3) making a search with the search base not in the cache.
>
> These operations are encountered while doing the following:
> 1) adding to the cache, an entry returned from the backend server, which
> does not have its parent in the cache.
> 2) removing an entry whose corresponding queries have been removed by cache
> replacement.
> 3) while searching the local cache for an answerable query with base entry
> not in the cache.
>
> For LDBM backend I could achieve the above by implementing  three
> additional interfaces for adding/merging, searching and removing. I am not
> sure if all of these can be taken care of by the existing interfaces for
> search/add/delete/modify.
>
> 1) can probably be achieved by adding as root. For 3) the only solution I
> could think of was to use the backend's suffix as the search base for all
> the cache searches and filter out the entries not in the subtree using the
> callback function for send_search_entry. This is not  very efficient.
>
> Would greatly appreciate any help in solving this problem.

I see the problem, not sure I have a good answer. It seems to me that you can
do one of two things - have the cache be an actual mirror/replica of the
target tree, or have the cache be a flat database. It looks like you want the
latter, but leveraging the caching and database interface of back-ldbm. I
believe it may have been more straightforward just to use libldbm directly.
However, you can get the same effect by  storing cache entries as a flat
one-level tree in any of the other backends. Name the cache entries by some
completely separate attribute, and store the entries' full DNs as an explicit
"dn" attribute inside the entry. Then you search for cache results using e.g.
(&(dn=*,ou=base,o=suffix)(cn=foo)(uid=foo))

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