> -----Original Message----- > From: Marcel Reutegger [mailto:[EMAIL PROTECTED] On Behalf Of Marcel > Reutegger > Sent: Tuesday, May 16, 2006 12:36 AM > To: [email protected] > 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:[EMAIL PROTECTED] > >> Sent: Thursday, May 11, 2006 10:03 PM > >> To: [email protected] > >> 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 > > > > > > > -- > -----------------------------------------< [EMAIL PROTECTED] >--- > 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 >---
