[Date Prev][Date Next]
Re: (ITS#6152) proxycache enhancements
> firstname.lastname@example.org 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
> could answer if the entry was already retrieved by some other query, but
> 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.
I was not concerned with *caching* the result of compare, but with
exploiting cached entries to answer compares without contacting the remote
> It seems to me that apps
> do Compares on a set of entries do that to avoid Searching and retrieving
> entire entry, so in practice the intersection of (entries cached by
> 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
>> 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
> 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
> 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
> have queryIDs that reference nonexistent queries.
> Yeah, Adds could result in a lot of invalidations too, with the same
> 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,