Discuss: cache invalidation hook

[William Brown <wibrown@xxxxxxxxxx>]

Hi,

As we are looking at the early stages of designing a plugin v4 api, I
wanted to discuss a new hook for this for cache invalidation.

http://www.port389.org/docs/389ds/design/plugin-v4.html

I would like to propose we add a new function hook such as:

SLAPI_V4_PLUGIN_CACHE_INVALIDATE.

This function would take:

slapi_v4_plugin_result *
cache_invalidate_hook(Slapi_PBlock *pb, const char *nsuniqueid) {
}

The idea is that on a modification,delete,modrdn of an entry, we don't
know what may be affected. For example, if we have an ACL cache of
nsuniqueid to actions / targets, we need to make sure that on a modrdn,
we invalidate this from the ACL plugin to force the aci's to be
re-evaluated for the objects new location.

By making this a generic plugin hook, any plugin can now:

* cache objects by the nsuniqueid
* rely on the framework to provided invalidation signals

This opens up many possibilities either for caches within the server to
be longer lived (for example, memberof) but without sacrificing
consistency.

An alternate solution would be for the server to have a "message bus" of
actions, and based on these changes you can make more finegrained
decisions. IE

SLAPI_V4_PLUGIN_CHANGE_NOTIFICATION

slapi_v4_plugin_result *
change_hook(Slapi_PBlock *pb, enum action, const char *nsuniqueid) {
}

enum action is:

{
    SLAPI_ADD
    SLAPI_MODIFY
    SLAPI_MODRDN
    SLAPI_DELETE
}

This would allow the construction of the cache invalidation mechanism,
but also auditing mechanisms and more. 


I would propose that these are run after after SLAPI_V4_PLUGIN_WR_POST_*
but before SLAPI_V4_PLUGIN_WR_COMMIT_FN. 


Does this seem like something we should investigate and add to the
document for future development?

-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Australia/Brisbane

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx