jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Giota Karadimitriou" <Giota.Karadimitr...@eurodyn.com>
Subject RE: jackrabbit & clustering
Date Fri, 12 May 2006 17:32:32 GMT
Hi Marcel (and list),

why in your opinion is Scenario 1 not sufficient? I try to think of it
logically and it makes sense. Assume Node with id "ID" gets modified by
cluster1 and the changes are persisted. Then

Shism1 (cluster1)-------sends state of node with id "ID" ---->shism2

Cluster2 has in the meantime already started also modifying Node with id
"ID" and therefore has a transient state for it. I find from Cluster2
the shared state 

ItemState is1 = copyOf(shism1.state);
ItemState is2 = shism2.getItemState(is1.getId();

which is wrapped by a local state and the local state wrapped again by
the transient state and notify (the shared state) that the database has
been updated for that item 


Shared state propagates event to the local state and this to the
transient state. Ideally all layers are now informed that a change has
happened in the underlying persistence storage and if the transient
state tries to save (and push), an exception should be thrown like
StaleException or sth.

This at least is my understading of the model based on the description
given by Dominique pfister a while ago

What would be the purpose of connect and push like you propose down

ItemState is1 = copyOf(shism1.state);
ItemState is2 = shism2.getItemState(is1.getId();


> -----Original Message-----
> From: Marcel Reutegger [mailto:marcel.reutegger@gmx.net]
> Sent: Thursday, May 11, 2006 10:03 PM
> To: dev@jackrabbit.apache.org
> Subject: Re: jackrabbit & clustering
> Giota Karadimitriou wrote:
> > The question is the following. Let's assume I have some modified
> > itemstates from shism1 and want to propagate the changes to shism2.
> > we r talking about non-transient and non-local changes
> > will do the job. If the state is local or transient there are 2
> > scenarios:
> > ----------------------------------------
> > Scenario 1) Is this sufficient?
> >
> > ItemState is= shism2.getItemState(id);
> > is.notifyStateUpdated()?
> > -----------------------------------
hi Marcel,

why the above scenario is not sufficient? Cluster 1 modifies an entry
and persists the change in the database. Cluster 2 who has in the
meantime changed something in this entry and has rendered its state to
be transient needs to be notified of the change   

> >
> >>From what you say it is not;
> > You suggest:
> > "connect the state from shism1 with the state from shism2 and then
> > the changes down. After that you have to trigger the appropriate
> > I'd say
> > notifyStateUpdated()."
> > However if the state already has an overlaid state, connecting it
> > throw exception.
> I assumed that you are not really connecting the state from shism1 but
> rather a copy of the state which is independant and does not have a
> overlayed state. otherwise you start connecting states from different
> cluster nodes and I guess that's definitively not desirable.
> > -----------------------------------------
> > Scenario 2) Is that what you propose?
> >
> > ItemState is= shism2.getItemState(id);
> > if (is.hasOverlayedState()){
> > 	is.disconnect();
> > }
> >
> > is.connect(shism1.state);
> > is.push();
> > is.notifyStateUpdated()?
> > -----------------------------------------
> hmm, not really. I might be wrong, but I still think that item states
> in a shared ism do *not* have an overlayed state in any case. they are
>   created by the persistence manager and are at the very bottom of the
> state stack.
> I was thinking more of something like the following (assuming that
> shism1 is the cluster node where the change was initiated):
> ItemState is1 = copyOf(shism1.state);
> ItemState is2 = shism2.getItemState(is1.getId();
> is1.connect(is2);
> is1.push();
> is2.notifyStateUpdated();

I had made a wrong assumption

> regards
>   marcel

View raw message