jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Giota Karadimitriou" <Giota.Karadimitr...@eurodyn.com>
Subject RE: jackrabbit & clustering
Date Wed, 03 May 2006 07:14:00 GMT

> -----Original Message-----
> From: Marcel Reutegger [mailto:marcel.reutegger@gmx.net]
> Sent: Tuesday, May 02, 2006 7:23 PM
> To: dev@jackrabbit.apache.org
> Subject: Re: jackrabbit & clustering
> Giota Karadimitriou wrote:
> >>From what I understand the main issue remaining is how to enforce
> > integrity. The ideal solution would be for the cache to be
> > between clusters; therefore for the cache to be persisted somewhere
> > (e.g. database) where both clusters nodes would be able to see it
> > it in some way);
> > Is this possible and what would I need to modify? I am just asking
> > some general guidelines to help me get started.
> >
> > Since our application uses a common database where everything
> > search indexs) will be stored; what happens after a successful
commit on
> > one cluster and switching to the other cluster? Does the cache
> > 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
> > cache and just read and write from the database. I know this would
> > 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
> > issues below?
> >
> > - SharedItemStateManager and its cache
> >     - cache integrity
> integrity is entirely controlled by the SharedISM. layers on top of
> SharedISM depend on listeners that get notified when an item state
> changes.

Thanks for the answers Marcel. One extra question: since shared item
state manager is entirely responsible for controlling integrity; is
there a way to check (by querying somehow the database) whether an item
state is up to date and if not to just reload it from the database.
Couldn't this ideally work for cluster since everything in our
application is being saved in a common database? (Of course performance
would go down with all these db calls but cache would become valid)

This way the itemstate would change and thus listeners would be notified
propagating the change to the upper layers.

Just let me know if this could be some possible scenario.

> >     - 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
> 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

View raw message