Re: (ITS#6152) proxycache enhancements

[hyc@symas.com]

masarati@aero.polimi.it wrote:
> 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/