> [email protected] wrote: >> I wonder, in the spirit of further improving pcache: > > I think this should be a separate ITS.
Well, based on your response, it seems not to deserve an ITS at all :) >> - 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. We have: a cached entry contains the pcacheQueryID, which solves the problem. > 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. Correct. > 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. I was not concerned with *caching* the result of compare, but with exploiting cached entries to answer compares without contacting the remote server. > 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. This is all already in place as the PCACHE_EXOP_QUERY_DELETE. > (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. pcache is probably based on the assumption that clients only perform search (and now, bind) operations, so it's a moot point anyway. > 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. Codewise, it's a matter of just calling pcache_remove_entry_queries_from_cache() for the request DN, if the modification succeeds. Performance and load-wise, it might not be worth, I concur. p.
