Page History

...

This concept is based on issue MGNLADVCACHE-10@jira found while testing clustering and subsequent discussion.

Use case

• page commenting
• any other non activation based content updates

EHCache

EHcache supports clustering.
Considerations for using EHcache clustering support:

...

• instances participating in the cluster are already bound together by JR journalling and only events related to clustered workspaces are propagated across cluster, no extra config necessary
• there is mechanism in place for instructing the cache (Flush policy) which works well in clustered environment
• the Flush Policy is already implemented for flushing all the content (and used for activation)
• new flush policy for flushing single only items would have to be implemented
• The advanced caching techniques manipulating cache items directly would need to be rewritten to use Observation for all cache manipulation to ensure events are propagated across cluster
• New method (since 4.1) for flushing single page from cache would need to be changed to use single page flush policy instead of retrieving cache instance and removing content directly

Implementation details

Cache updates should be realized only via observation to ensure distribution over the cluster.
Schema of the implementation for page commenting based on observation
Image Added
First code changes have been commited.
In cache module:

• New methods in CachePolicy API to allow exposing conversion of uuid to cache key, should the cache policy support this.
• Implementation of the above for Default cache policy.
  In commenting module:
• Implementation of the flush policy that is able to detect page that needs to be flushed based on new comments being added.
• Registration of the above policy on the startup of the module

Pending

• peer review
• what might still change
  • is some method naming, and
  • probably final location for the code related to flushing the page in the policy. Since this is rather generic, it might be moved to either cache or advanced cache module to expose functionality to the others who might be interested in using it.
  • initialization of the flush policy ... still undecided whether it is really business of the commenting module to register this or whether cache module should take care.
  • configuration - is it enough that there is only this one policy that can be used with commenting, or is there a real chance that we or someone else might ever want to replace it with something else in some case.