You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Guozhong (Richard) Wang" <gu...@oracle.com> on 2005/07/13 23:04:33 UTC
jackrabbit deployment model 1
Hi,
On the "Model 1: The (Web-) Application Bundle HOWTO
<http://incubator.apache.org/jackrabbit/arch/deploy/howto-model1.html>"
web page, there is a note: "remember that two Jackrabbit instances
should never read from/write to the same physical storage. This setup is
not supported and will lead to corrupt data."
Can anyone explain why there is such an restriction? Why two sessions
from the same Jackrabbit instance could read from/write to the same
physical storage, but not two sessions from two Jackrabbit instances?
I appreciate your input.
thanks,
Richard
Re: jackrabbit deployment model 1
Posted by Julien Viet <ju...@jboss.org>.
ok, thanks for the info.
as I said in another mail, do you have doc to share on the design ?
Marcel Reutegger wrote:
> Hi Julien,
>
> Julien Viet wrote:
>
>> usually a cache is supposed to keep object with an eviction policy.
>
>
> The eviction policy for the cache that the SharedItemStateManager is
> using is a bit unusual because it includes the rule, that no object
> may be removed from the cache as long as it is referenced by a
> transaction. But otherwise I think the name is quite ok.
>
>> in that case I suppose the policy is : keep no objects.
>
>
> well, that's not possible because of the above rule.
>
> regards
> marcel
>
--
Julien Viet
JBoss Portal Lead Developer
Re: jackrabbit deployment model 1
Posted by Marcel Reutegger <ma...@gmx.net>.
Hi Julien,
Julien Viet wrote:
> usually a cache is supposed to keep object with an eviction policy.
The eviction policy for the cache that the SharedItemStateManager is
using is a bit unusual because it includes the rule, that no object may
be removed from the cache as long as it is referenced by a transaction.
But otherwise I think the name is quite ok.
> in that case I suppose the policy is : keep no objects.
well, that's not possible because of the above rule.
regards
marcel
Re: jackrabbit deployment model 1
Posted by Julien Viet <ju...@jboss.org>.
usually a cache is supposed to keep object with an eviction policy.
in that case I suppose the policy is : keep no objects.
otherwise I would not call that a cache but a map or registry.
Stefan Guggisberg wrote:
>On 7/14/05, Julien Viet <ju...@jboss.org> 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)
>>
>>
>
>what would you expect if you'd mess around at the very core of a
>repository/rdbms?
>
>
>
>>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
>>
>>
>>
>>
>
>
>
--
Julien Viet
JBoss Portal Lead Developer
Re: jackrabbit deployment model 1
Posted by Stefan Guggisberg <st...@gmail.com>.
On 7/14/05, Julien Viet <ju...@jboss.org> 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)
what would you expect if you'd mess around at the very core of a
repository/rdbms?
>
> 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
>
>
Re: jackrabbit deployment model 1
Posted by Edgar Poce <ed...@gmail.com>.
Hi richard
Please correct me if I'm wrong. I think you can deploy your j2ee
application in a load balancing cluster through the container
capabilities and configure each node to access the same jackrabbit
instance through any of the available strategies for model 3
deployments (client server), i.e. webdav or rmi. Depending on your app
needs I think it might be a good solution.
does it make sense?
BR,
edgar
On 7/14/05, Guozhong (Richard) Wang <gu...@oracle.com> wrote:
> Julien and Marcel,
>
> Thanks for the clarification. Now I understand it's the internal cache
> that prevents multiple Repos from accessing the storage at the same
> time. This design makes sense as it has better performance than the one
> without the cache. But if the internal cache is disabled as Julien did,
> in theory should multiple Repos be able to simultaneously access the
> storage?
>
> 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
> >>
> >
> >
>
>
Re: jackrabbit deployment model 1
Posted by Julien Viet <ju...@jboss.org>.
in theory yes
the items would be loaded when needed and discarded at the end of the
session.
caching is just here to ensure good performances and avoid to go to the
persistent storage all the time.
Guozhong (Richard) Wang wrote:
> Julien and Marcel,
>
> Thanks for the clarification. Now I understand it's the internal cache
> that prevents multiple Repos from accessing the storage at the same
> time. This design makes sense as it has better performance than the
> one without the cache. But if the internal cache is disabled as Julien
> did, in theory should multiple Repos be able to simultaneously access
> the storage?
>
> 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
Re: jackrabbit deployment model 1
Posted by Stefan Guggisberg <st...@gmail.com>.
On 7/14/05, Edgar Poce <ed...@gmail.com> wrote:
> Hi richard
>
> On 7/14/05, Guozhong (Richard) Wang <gu...@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.
edgar is perfectly right. the purpose of SharedItemStateManager is not
just to provide caching on the persistence layer for better performance.
SharedItemStateManager plays an crucial role in jackrabbit's implementation
of isolation levels. it guarantees that there exists at most just one ItemState
instance per id at any time. that's why it's not called
*SharedItemStateCache* ;)
disabling caching is therefore not a very good idea and i am not
surprised at all
that some test cases fail if you do so.
cheers
stefan
>
> 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
> > >>
> > >
> > >
> >
> >
>
Re: jackrabbit deployment model 1
Posted by Stefan Guggisberg <st...@gmail.com>.
On 7/18/05, Julien Viet <ju...@jboss.org> wrote:
> yes, at the end jackrabbit is a database.
>
> btw do you have any doc to share on the SharedItemStateManager ?
touché ;) i am perfectly aware that a lot needs to be done in the documentation
area. we just didn't get around to do it. we'll improve it gradually
as time allows.
for the time being i suggest you search the mail archives. there were a
couple of threads discussing/explaining jackrabbit's core design.
cheers
stefan
>
> Stefan Guggisberg wrote:
>
> >On 7/15/05, Marcel Reutegger <ma...@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
>
>
Re: jackrabbit deployment model 1
Posted by Julien Viet <ju...@jboss.org>.
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 <ma...@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
Re: jackrabbit deployment model 1
Posted by David Nuescheler <da...@gmail.com>.
hi julien,
> each node has 2 maps :
>
> one for children node
> one for the content of the node (where you put 1 million object)
>
> so it performs as well as the underlying map performs, afair it should
> be a ConcurrentHashMap.
>
> so you can really consider jbosscache as a flat cache by using the root
> node to store you objects and not create children for it.
i am in contact with bela regarding that.
i think there are mixed feelings / comments about using jboss
cache in flat manner.
it is quite high on my agenda to arrange a more in-depth
discussion around that.
i really think jboss cache is very interesting, and i am looking
forward to a very inspiring conversation regarding that.
regards,
david
Re: jackrabbit deployment model 1
Posted by Julien Viet <ju...@jboss.org>.
each node has 2 maps :
one for children node
one for the content of the node (where you put 1 million object)
so it performs as well as the underlying map performs, afair it should
be a ConcurrentHashMap.
so you can really consider jbosscache as a flat cache by using the root
node to store you objects and not create children for it.
Stefan Guggisberg wrote:
>On 7/18/05, Marcel Reutegger <ma...@gmx.net> wrote:
>
>
>>Stefan Guggisberg wrote:
>>
>>
>>>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 know JBoss Cache in detail, but as far as I can see you may use
>>it also with a flat data model. In the end it's an id anyway, whether it
>>is a path or a simple string.
>>
>>
>
>in theory, sure. i wonder how JBoss Cache (a tree cache by design)
>would perform with a flat data model of > 1 million sibling nodes....
>
>
>cheers
>stefan
>
>
>
>>>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.
>>>
>>>
>>I still think that the contract for the SharedItemStateManager can be
>>described in a very concise way and that also applies to the cache it is
>>using. Once those contracts are described I don't see a reason why it
>>shouldn't be possible to use another implementation.
>>
>>
>>
>>>>With the risk that someone will probably try to kill me on monday I
>>>>
>>>>
>>>;)
>>>
>>>
>>btw, that's not the reason why I'm working from home today.
>>It's the U2 concert in zurich tonight ;)
>>
>>regards
>> marcel
>>
>>
>>
>
>
>
--
Julien Viet
JBoss Portal Lead Developer
Re: jackrabbit deployment model 1
Posted by Stefan Guggisberg <st...@gmail.com>.
On 7/18/05, Marcel Reutegger <ma...@gmx.net> wrote:
> Stefan Guggisberg wrote:
> > 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 know JBoss Cache in detail, but as far as I can see you may use
> it also with a flat data model. In the end it's an id anyway, whether it
> is a path or a simple string.
in theory, sure. i wonder how JBoss Cache (a tree cache by design)
would perform with a flat data model of > 1 million sibling nodes....
cheers
stefan
>
> > 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.
>
> I still think that the contract for the SharedItemStateManager can be
> described in a very concise way and that also applies to the cache it is
> using. Once those contracts are described I don't see a reason why it
> shouldn't be possible to use another implementation.
>
> >>With the risk that someone will probably try to kill me on monday I
> >
> > ;)
>
> btw, that's not the reason why I'm working from home today.
> It's the U2 concert in zurich tonight ;)
>
> regards
> marcel
>
Re: jackrabbit deployment model 1
Posted by Marcel Reutegger <ma...@gmx.net>.
Stefan Guggisberg wrote:
> 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 know JBoss Cache in detail, but as far as I can see you may use
it also with a flat data model. In the end it's an id anyway, whether it
is a path or a simple string.
> 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.
I still think that the contract for the SharedItemStateManager can be
described in a very concise way and that also applies to the cache it is
using. Once those contracts are described I don't see a reason why it
shouldn't be possible to use another implementation.
>>With the risk that someone will probably try to kill me on monday I
>
> ;)
btw, that's not the reason why I'm working from home today.
It's the U2 concert in zurich tonight ;)
regards
marcel
Re: jackrabbit deployment model 1
Posted by Stefan Guggisberg <st...@gmail.com>.
On 7/15/05, Marcel Reutegger <ma...@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
>
Re: jackrabbit deployment model 1
Posted by Serge Huber <sh...@jahia.com>.
Marcel Reutegger wrote:
>
> I had a look at JBoss Cache the other day, and I think it looks
> promissing indeed.
> 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
Funny, I've just been comparing cache system, especially for clustering
needs. JBoss Cache is interesting, although a bit peculiar in it's
implementation. I think that Jackrabbit should not become specific to a
cache implementation though, and use an interface to caches, such as
what has been done in Hibernate and OJB for cache providers (example of
OSCache provider for Hibernate here :
http://www.opensymphony.com/oscache/wiki/Hibernate%20Cache%20Provider.html
and
http://www.opensymphony.com/oscache/wiki/Hibernate%20Cache%20Adapter.html).
There are tons of cache implementations out there, ranging from very
light-weight to full-blown commercial ones. One of the most interesting
concepts in recent caches in the notion of cache groups, which allows
for "categorization" of cache entries, so that flushing can be done on
one group (or category). Unfortunately there is no standard for this
feature and I haven't found an equivalent in JBoss Cache (I looked at
building groups as sub nodes, but somehow it doesn't work the same way).
The nice thing about JBoss cache is that it handles transactions over a
cluster, so that makes it very interesting for highly critical scenarios.
Regards,
Serge Huber.
Re: jackrabbit deployment model 1
Posted by Marcel Reutegger <ma...@gmx.net>.
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.
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
regards
marcel
Re: jackrabbit deployment model 1
Posted by Julien Viet <ju...@jboss.org>.
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 <gu...@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
Re: jackrabbit deployment model 1
Posted by Edgar Poce <ed...@gmail.com>.
Hi richard
On 7/14/05, Guozhong (Richard) Wang <gu...@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
> >>
> >
> >
>
>
Re: jackrabbit deployment model 1
Posted by "Guozhong (Richard) Wang" <gu...@oracle.com>.
Julien and Marcel,
Thanks for the clarification. Now I understand it's the internal cache
that prevents multiple Repos from accessing the storage at the same
time. This design makes sense as it has better performance than the one
without the cache. But if the internal cache is disabled as Julien did,
in theory should multiple Repos be able to simultaneously access the
storage?
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
>>
>
>
Re: jackrabbit deployment model 1
Posted by Julien Viet <ju...@jboss.org>.
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
Re: jackrabbit deployment model 1
Posted by Marcel Reutegger <ma...@gmx.net>.
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
Re: jackrabbit deployment model 1
Posted by Julien Viet <ju...@jboss.org>.
because jackrabbit uses an internal cache that you cannot disable.
so if one instance modify the physical storage, the other instance will
not be aware of the change and use wrong data and possibly corrupt the
data integrity
cheers
Guozhong (Richard) Wang wrote:
> Hi,
>
> On the "Model 1: The (Web-) Application Bundle HOWTO
> <http://incubator.apache.org/jackrabbit/arch/deploy/howto-model1.html>"
> web page, there is a note: "remember that two Jackrabbit instances
> should never read from/write to the same physical storage. This setup
> is not supported and will lead to corrupt data."
>
> Can anyone explain why there is such an restriction? Why two sessions
> from the same Jackrabbit instance could read from/write to the same
> physical storage, but not two sessions from two Jackrabbit instances?
>
> I appreciate your input.
>
> thanks,
> Richard
>
--
Julien Viet
JBoss Portal Lead Developer