jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <marcel.reuteg...@day.com>
Subject Re: jackrabbit & clustering
Date Mon, 15 May 2006 21:35:49 GMT
Giota Karadimitriou wrote:
> 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)
> 
> 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 
> 
> is2.notifyUpdated(); 
> 
> 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
> 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 local 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

> 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