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 Thu, 18 May 2006 17:50:51 GMT


> -----Original Message-----
> From: Marcel Reutegger [mailto:mreutegg@gmail.com] On Behalf Of Marcel
> Reutegger
> Sent: Tuesday, May 16, 2006 12:36 AM
> To: dev@jackrabbit.apache.org
> Subject: Re: jackrabbit & clustering
> 
...
> > What would be the purpose of connect and push like you propose down
> > here?
> >
> > ItemState is1 = copyOf(shism1.state);
> > ItemState is2 = shism2.getItemState(is1.getId();
> > is1.connect(is2);
> > is1.push();
> > is2.notifyStateUpdated();
> 
> if steps 3 and 4 are omitted, is2 is still the now stale copy in
shism2.
> calling notifyStateUpdated() will indeed notify the l.ocal and
transient
> states of shism1, but those states will not be brought to the change
> version as saved in shism1.
> 
> the push is needed imo to propagate the change from shism1 to shism2
and
> from there to the local and transient states.
> 
> regards
>   marcel
Much obliged for your answer Marcel, things are starting to make sense
thanks to you. Allow me one extra question which again creates confusion
for me:
is1 is just a copy of a shism1 state, so it does not exist in shism2; it
is just transferred to shism2 (using rmi assumingly)

By is1.connect(is2); we make is2 overlaid state of is1 and we add is1 as
listener. then push() copies information from is1 to is2. so far so
good. However, isn't it a problem that is1 in reality does not exist for
shish2?
It is like an unlinked object state (a copy of an object with no
binding/relation to shism2).  Don't we lose the is2 transient state this
way? 
 

> 
> > regards
> > Giota
> >
> >
> >> -----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.
> > If
> >>> we r talking about non-transient and non-local changes
> > cache.evict(id)
> >>> 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
> > push
> >>> the changes down. After that you have to trigger the appropriate
> > event.
> >>> I'd say
> >>> notifyStateUpdated()."
> >>> However if the state already has an overlaid state, connecting it
> > will
> >>> 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
> >
> >
> 
> 
> --
> -----------------------------------------< marcel.reutegger@day.com
>---
> Marcel Reutegger, Day Software AG, Barfuesserplatz 6, CH - 4001 Basel
> T +41 61 226 98 98, F +41 61 226 98 97
> -----------------------------------------------< http://www.day.com
>---



Mime
View raw message