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 Mon, 18 Jul 2005 09:47:38 GMT
yes, at the end jackrabbit is a database.

btw do you have any doc to share on the SharedItemStateManager ?

Stefan Guggisberg wrote:

>On 7/15/05, Marcel Reutegger <marcel.reutegger@gmx.net> wrote:
>  
>
>>Hi Julien,
>>
>>Julien Viet wrote:
>>    
>>
>>>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.
>>>      
>>>
>>We have ongoing (tough private coffee break) discussions here at day
>>about clustering. The reason why we are not pushing such a feature right
>>now is, that it would require a redesign of one of the very central core
>>pieces of jackrabbit. I can only speak for myself, but I rather want to
>>release a stable single instance version of jackrabbit, than a release
>>with clustering support that turns out to be not reliable.
>>
>>    
>>
>>>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.
>>>      
>>>
>>I had a look at JBoss Cache the other day, and I think it looks
>>promissing indeed.
>>    
>>
>
>i had a quick glance at JBoss Cache as well. i agree that it looks 
>promising, but not for use in jackrabbit's core. 
>
>for one JBoss Cache is hierarchical (i.e. path-based) whereas jackrabbit's
>internal data model is flat (id-based). 
>
>i don't think that crucial components at the very core should be pluggable.
>the contract of SharedItemStateManager is quite complex. if it's not
>implemented correctly the stability and integrity of the repository is at 
>great risk. do you know of any rdbms engine that supports pluggable 
>caches for its internal row buffers? i don't.
>
>  
>
>>With the risk that someone will probably try to kill me on monday I
>>    
>>
>
>;)
>
>  
>
>>opened a jira issue to start a more technical discussion about
>>clustering and what is needed to make this possible in jackrabbit:
>>http://issues.apache.org/jira/browse/JCR-169
>>    
>>
>
>good starting point!
>
>cheers
>stefan
>
>  
>
>>regards
>>  marcel
>>
>>    
>>
>
>  
>


-- 
Julien Viet
JBoss Portal Lead Developer


Mime
View raw message