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:[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 >---
