jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julien Viet <jul...@jboss.org>
Subject Re: jackrabbit deployment model 1
Date Thu, 14 Jul 2005 15:34:06 GMT
we are considering using jackrabbit in JBoss Portal for our CMS and so 
far, the only way we have to use it is having
an architecture where the repository runs as a singleton (we have an HA 
singleton service) on the cluster
and other nodes use proxies to talk to the master node. Also we would 
add lot of caching but not at the
JCR level but at the layer above which is the CMS object model in order 
to provide a fast access to clients.

the other ideas would to plug JBoss Cache (distributed transactionnal 
cache) in jackrabbit but there are no hooks to
do that so far. My trick about disabling the jackrabbit cache is that I 
reimplemented a jackrabbit filesystem on top
of JBoss Portal to provide replication. It worked but some tests are not 
passing in jackrabbit suite and I did not check
further (no time). Having such an integration would require I think 
modifications in jackrabbit. Perhaps JBoss Cache
should be plugged at the SharedItemState level.

If you think about it, JBoss Cache does already what jackrabbit is doing 
is some ways. It is possible to configure it
to have a cache loader that can load and store cache entries. It is 
comparable to SharedItemStateCache and PersistenceManager
you have in your codebase. The difference is that the cache can be 
replicated and also provide a configurable isolation level, also
we are in the process of adding optimistic locking.

Edgar Poce wrote:

>Hi richard
>
>On 7/14/05, Guozhong (Richard) Wang <guozhong.wang@oracle.com> wrote:
>  
>
>>Julien and Marcel,
>>
>>But if the internal cache is disabled as Julien did,
>>in theory should multiple Repos be able to simultaneously access the
>>storage?
>>    
>>
>
> I don't think so. The concurrency control is done at the
>SharedItemStateManager level (see
>http://issues.apache.org/jira/browse/JCR-164). So, two jackrabbit
>instances accessing the same physical storage will probably lead to
>corrupt data. And among other problems, the search index on each
>instance would be unaware of the changes made by the other, and the
>observation wouldn't work as expected.
>
>As marcel already said, clustering is not that easy
>
>BR,
>edgar
>
>  
>
>>thanks,
>>Richard
>>
>>Julien Viet wrote:
>>
>>    
>>
>>>If you disable the cache then you reload everything all the time and
>>>should achieve the desired effect, but performances will suffer a lot.
>>>
>>>By the way I disabled the cache in jackrabbit (I simple modified the
>>>code to have the SharedItemCache have the put() do a noop).
>>>
>>>Some tests were not passing with that change. I think it is not normal
>>>to have the tests failing when the cache is disabled (even if it
>>>is uses a hack to make it not effective)
>>>
>>>Marcel Reutegger wrote:
>>>
>>>      
>>>
>>>>Julien Viet wrote:
>>>>
>>>>        
>>>>
>>>>>because jackrabbit uses an internal cache that you cannot disable.
>>>>>          
>>>>>
>>>>
>>>>and even if you would be able to disable the cache, one instance had
>>>>to tell the other one that something has changed on disc. otherwise
>>>>you would have to scan the filesystem all the time for possible changes.
>>>>
>>>>clustering is not that easy ;)
>>>>
>>>>regards
>>>> marcel
>>>>
>>>>        
>>>>
>>>      
>>>
>>    
>>
>
>  
>


-- 
Julien Viet
JBoss Portal Lead Developer


Mime
View raw message