jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Giota Karadimitriou" <Giota.Karadimitr...@eurodyn.com>
Subject jackrabbit & clustering
Date Tue, 02 May 2006 10:33:59 GMT
I would like to post an email to the list regarding jackrabbit &
clustering. I understand clustering behaviour is considered as low
however I think that many people (myself included) are eager to see this
issue progressing because many J2EE applications require clustering.
I have been following
http://issues.apache.org/jira/browse/JCR-169?page=all and trying to
understand the direction towards which the development efforts should be
guided in order for jackrabbit to work on cluster. I have also read the
email of Dominique Pfister sent almost a year ago describing 
the jackrabbit model quite well
Our application uses jackrabbit wrapped up as resource adapter using
JCA. We use SimpleDBPersistenceManager + DBFileSystem with externalBlobs
= true to ensure transactional behavior.
I am now in the process of modifying jackrabbit code in order to save
indexes in the database (and not in the file system); which means
*everything* will now be saved in the database. This will eliminate the
search index problem since the database is visible from both nodes of
the cluster. Furthermore our application does not require the
registration of any node types or namespaces at runtime. Finally we do
not require locking since we have an external locking mechanism. This
eliminates 3 of the clustering problems.
I would therefore like some assistance on where to start regarding the
other issues. I am really at loss here so I will try to talk simple;
forgive my ignorance.
>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? 
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? 
Could somebody from the list provide any additional help in any of the
issues below? 
- SharedItemStateManager and its cache 
    - cache integrity 
    - cache design: look aside, write through? 
    - hook for distributed cache, interface? 
    - isolation level 
    - transaction integrity within Jackrabbit, interaction with
transient layer 
- VirtualItemStateProvider 
    - same strategy as SharedItemStateManager? 
- Observation
- referential integrity (REFERENCE properties): changes need to be
- versioning: changes need to be syndicated
Any help would be important. 

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message