It sounds to me like a layer upon a cache is needed to be able to "tag" cache items with categorization. Then, it is up to the app to choose in it's life cycle when to clear certain cache tags.
For example, if you want data to be cleared upon internal redirect, you would label it as such "internal redirect" in the "Clear" Tag List. Then you would call a function upon internal direct saying
clear_tag_list("internal redirect") which would clear out all items with that tag.
Likewise, if you switch realms you would do something like
clear_tag_list("realm") for those cache items that were identified as being associated with a realm.
Then, it is up to your app framework to make use of this cache tagging feature that is specific to your app framework's app life cycle. The life cycle will, of course, be different from app framework to app framework even if there are many similarities.
Rob Nagler wrote:
One problem I didn't see addressed: partial context clearing before
internal redirects. We didn't consider this problem in our first cut,
but later added "put_durable" to our Request (context) object. Once
we get around to it, we will be clearing non-durable state when an
internal redirect happens. The solves a nasty problem of unwanted
cached state in the context across "tasks" (request processing). It's
too big of a job to refactor all our old code, so we're stuck with
some defects related to unexpected cached state and clearing state
manually before an internal redirect.
The concept is also important in executing "tasks" from the command
line or in background web jobs. If you are iterating through a list
of users doing some thing (e.g. sending subscription renewal notices),
you need to clear the state between each iteration.
Another problem with unexpected cache state is when you change
security realms. The context must be sensitive to realm changes and
clear state (ACLs, data) associated with the old security realm before
entering the new realm.
Rob
