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
