jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <marcel.reuteg...@gmx.net>
Subject Re: jackrabbit & clustering
Date Tue, 02 May 2006 16:22:33 GMT
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.


View raw message