> -----Original Message----- > From: Marcel Reutegger [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 02, 2006 7:23 PM > To: [email protected] > Subject: Re: jackrabbit & clustering > > 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.
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 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
