Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (asf.osuosl.org: domain of marcel.reutegger@gmx.net
 designates 213.165.64.20 as permitted sender)
Message-ID: <44638A56.8070609@gmx.net>
Date: Thu, 11 May 2006 21:02:46 +0200
From: Marcel Reutegger <marcel.reutegger@gmx.net>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: dev@jackrabbit.apache.org
Subject: Re: jackrabbit & clustering
References: <00f001c67509$4cff40f0$b6fdfe0a@gkaradimitr>
In-Reply-To: <00f001c67509$4cff40f0$b6fdfe0a@gkaradimitr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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()?
> -----------------------------------
> 
>>>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();

regards
  marcel