jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Giota Karadimitriou" <Giota.Karadimitr...@eurodyn.com>
Subject RE: jackrabbit & clustering
Date Thu, 11 May 2006 14:43:43 GMT


> -----Original Message-----
> From: Marcel Reutegger [mailto:marcel.reutegger@gmx.net]
> Sent: Thursday, May 11, 2006 12:25 PM
> To: dev@jackrabbit.apache.org
> Subject: Re: jackrabbit & clustering
> 
> Giota Karadimitriou wrote:
> > What I want to accomplish is let the other shisms know that the
> > persistent storage that these states depend upon, has changed. I
took a
> > more careful look at the code but the problem is that I don't know
where
> > to fire the proper events... should it be on the item state itself
or on
> > the underlying item state of an item state.
> 
> the state events should be triggered on the shared states. those are
at
> the very
> bottom and will never have an overlayed state.
> 
> > What should I do if the underlying state does not exist?
> 
> this depends on what exactly you mean by 'it does not exist'. 1) if
you
> mean that the
> state does not exist in the cache of the shism then the state can
simply
> be loaded
> from persistent storage. an alternative design is to send not just the
ids
> of the
> states that changed but the whole state. this allows other shism to
> process the
> change without having to call the persistence manager. 2) if you mean
that
> the state
> does not exist anymore at all, this can only be caused by a item
remove
> operation. in
> that case the state needs to be destroyed anyway and is not of
interest
> anymore.
> 
> > I tried to answer these questions
> > myself however I do not know if I am on the right path. Please take
a
> > look at the following draft code regarding just the modified states.
> >
> > For all ids where *id* is obtained from shism1.shared.modified do
for
> > shism2..shismn:
> >
> > Iterator it=shism1.shared.modifiedStates();
> >
> > while (it.hasNext()){
> >
> >       Object state = (ItemState)it.next();
> >       ItemId id=state.getId();
> > if (shism2.hasItemState(id)) {
> > 	if (shism2.hasNonVirtualItemState(id)){
> > 		if (shism2.cache.isCached(id))
> >     			shism2.cache.evict(id)
> > 		} else {
> > 			//virtual or transient
> > 			ItemState is= shism2.getItemState(id);
> > 			//WHAT TO DO NOW? IS THIS CORRECT?
> 
> at this point I'd say you have to connect the state from shism1 (I
assume
> this is a
> copy of the state) with the state from shism2 and then push the
changes
> down. after
> that you have to trigger the appropriate event. I'd say
> notifyStateUpdated().

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

Thanks
Giota

> 
> > 			if (is.hasOverlayedState()){
> > 	    			ItemState over= is.getOverlayedState();
> > 				//over.copy(state);   necessary?
> > over.notifyStateUpdated();
> > 			} else {
> > 				// use shism2.loadItemState(id) instead
> > of state?
> > 	    			is.connect(state);
> > 			}
> >
> > 		}
> > 	}
> >
> > }
> > }
> >
> > Again many thanks for the support you have provided me with so far.
I do
> > not want to monopolize the list with my questions however some
things in
> > the code are difficult to understand without help.
> 
> don't worry, that's the purpose of this list.
> 
> regards
>   marcel


Mime
View raw message