[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: commit: ldap/servers/slapd/overlays pcache.c
hyc@OpenLDAP.org wrote:
Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays
Modified Files:
pcache.c 1.168 -> 1.169
Log Message:
Partially revert 1.32; pcache must allow other callbacks to see its results
Regarding the original reason for this change...
It's clear that what we really want is for pcache to behave the same in the
cached vs uncached case, wrt other overlays/callbacks. So wherever pcache
takes control in the call stack for the uncached case, it should do the same
in the cached case.
What's not clear is how to do that in general. When "response-callback head"
has been configured, it should just execute and leave the callback stack
intact when answering from cache. When "tail" (the default) is in effect then
it probably should bypass the stack. The above commit just leaves the stack
intact; I'll fix it up now to depend on the response-callback setting.
* To: OpenLDAP Commit <openldap-commit2devel@OpenLDAP.org>
* Subject: Re: commit: ldap/servers/slapd/overlays pcache.c
* From: Pierangelo Masarati <ando@sys-net.it>
* Date: Tue, 24 Aug 2004 10:40:00 +0200
ando@OpenLDAP.org wrote:
Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays
Modified Files:
pcache.c 1.31 -> 1.32
Log Message:
- proxy cache erroneously returns the filtering attributes
and the objectClass right after caching, even if not requested,
while subsequent searches are fine;
I think this is a bug; it was also reflected in the test data, which has been
fixed accordingly
- the response callback needs be apended at the end of the
callback list, otherwise the resulting entries are cached
I ran into this issue while developing an overlay that dynamically builds
entries; the raw entry was being cached instead of the completed one,
because pcache adds its callback only when required, while that of my
overlay is stacked by the overlay infrastructure. I think the "natural"
behavior of pcache is to cache the final result that is sent to the user.
I guess there might be applications where this is not true, so I made the
original behavior configurable by an (undocumented) directive.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/