Giota Karadimitriou wrote:
From what I understand the main issue remaining is how to enforce cache
integrity. The ideal solution would be for the cache to be propagated
between clusters; therefore for the cache to be persisted somewhere
(e.g. database) where both clusters nodes would be able to see it (&load
it in some way);
Is this possible and what would I need to modify? I am just asking for
some general guidelines to help me get started.
Since our application uses a common database where everything (including
search indexs) will be stored; what happens after a successful commit on
one cluster and switching to the other cluster? Does the cache notice
the change and gets invalidated? How to enforce such a thing?
caching in jackrabbit is not cluster aware, it assumes that it is the
only 'application' working on the data in the persistence manager.
Another solution (possible the worst one) would be to totally inactivate
cache and just read and write from the database. I know this would ruin
performance but how could I do this if I wanted to?
this is not possible. jackrabbit has design restrictions that requires
some caching in the different item state layers. you would have to
significantly rewrite jackrabbit.
Could somebody from the list provide any additional help in any of the
issues below?
- SharedItemStateManager and its cache
- cache integrity
integrity is entirely controlled by the SharedISM. layers on top of the
SharedISM depend on listeners that get notified when an item state changes.
- cache design: look aside, write through?
it's a look aside cache.
- hook for distributed cache, interface?
there is an interface for caching item states: ItemStateCache. but
caching is not pluggable in jackrabbit.
- isolation level
items are visible to other transactions as soon as they are committed.
-> read-committed.
- transaction integrity within Jackrabbit, interaction with
transient layer
consistency is maintained by using a read-write lock on the SharedISM.
- VirtualItemStateProvider
- same strategy as SharedItemStateManager?
I'm not sure here, but I think it also uses a SharedISM underneath.
- Observation
is closely tied into the SharedISM and triggered when the transaction
was successfully committed.
- referential integrity (REFERENCE properties): changes need to be
syndicated/enforced
this is also done right before the commit while holding a write-lock on
the SharedISM. This prevents other sessions from e.g. removing the
target of a reference while committing the reference.
- versioning: changes need to be syndicated
I think if you are able to solve clustering for regular content, then
you should also be able to get it work with the version storage. in
jackrabbit the implementation of workspace content and the version
storage share quite a lot of the code.
regards
marcel
