[Date Prev][Date Next]
Re: (ITS#6152) proxycache enhancements
> I wonder, in the spirit of further improving pcache:
I think this should be a separate ITS.
> - support compare, in case a cached query has the entry to be compared,
> and the asserted attr is in the corresponding attrset?
Right now we have no convenient way to map a DN to a cached query. I guess we
could answer if the entry was already retrieved by some other query, but we
can't tell what the queryID is without first retrieving the entry. If the
entry doesn't exist locally, we have no way to map the request to a query
template, so we can't cache that result at all. It seems to me that apps that
do Compares on a set of entries do that to avoid Searching and retrieving the
entire entry, so in practice the intersection of (entries cached by searching)
and (entries we want to compare on) will be empty.
> - exploit modifications to invalidate queries whose results are altered?
> It'd be easy for deletes (check if present, and eventually remove the
> entry). An easy shortcut for modify/rename would be to just invalidate
> queries affecting the modified entry (I'd prefer this to mimic
> modifications to local data, which would also guarantee that remote server
> ACLs have been applied). Adds would be a little bit tricky (try all
> cached queries on the new entry (base, scope, filter; in case of match,
> invalidate them, so that the remote server can apply ACLs).
> This may be a moot point, as usually cached proxies are essentially
> read-only, but in case...
So far no one has asked for this functionality, thankfully.
We can retrieve an entry and read its queryID but we don't currently have an
easy way to look up the ID to get the CachedQuery info. (I guess we can put
them all into an AVL tree for the purpose.) That would make Deletes easy
enough I guess. For Modify/Rename, if you invalidate a query do you then
delete all of the cached entries for that query? That could result in a lot of
write traffic for a single change. Or do you just leave the cached entries
alone, and destroy the CachedQuery structures? Then the entries will simply
have queryIDs that reference nonexistent queries.
Yeah, Adds could result in a lot of invalidations too, with the same question
about dangling queryIDs.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/