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 Tue, 09 May 2006 17:45:22 GMT


> -----Original Message-----
> From: Marcel Reutegger [mailto:marcel.reutegger@gmx.net]
> Sent: Tuesday, May 09, 2006 11:03 AM
> To: dev@jackrabbit.apache.org
> Subject: Re: jackrabbit & clustering
> 
> Giota Karadimitriou wrote:
> > Hi Marcel and the rest of the list,
> >
> > please bear with me once more. I would like to ask if the following
> > scenario makes sense before applying it in practice.
> >
> > Let's assume that I have 2 clustered nodes and that I am able to
access
> > the shareditemstatemanagers on both (possibly I will make some
wrapper
> > around shareditemstatemanager and use rmi or sth to accomplish this
but
> > this part comes of second importance now).
> >
> > I will name them shism1 and shism2 where shism1=shared item state
> > manager on cluster node 1 and shism2=shared item state manager on
> > cluster node 2
> > (shismn==shared item state manager on cluster node n).
> >
> > a) First problem is making the write lock distributed. I though that
> > maybe this could be accomplished by doing the following:
> >
> > When invoking shism1.acquireWriteLock override it in order to also
> > invoke
> > shism2.acquireWriteLock  ... shismn.acquireWriteLock
> >
> > This way the write lock will have been acquired on all
> > shareditemstatemanagers.
> >
> > b) Once the update operation is finished and the changes are
persisted
> > in permanent storage perform the rest 2 operations:
> >
> > 1. shism1.releaseWriteLock (I will create such a method)
> > which will perform
> >
> > // downgrade to read lock
> >                 acquireReadLock();
> >                 rwLock.writeLock().release();
> >                 holdingWriteLock = false;
> >
> > and which be invoked on all the shared item state managers 2,3...n
> > shism2.releaseWriteLock  ... shismn.releaseWriteLock
> >
> > Before releasing the write lock I will also perform
> >
> > shism2.cache.evict(...),  shismn.cache.evict(...)
> >
> > where (...) will be all the itemstate ids that existed in
shism1.shared.
> >
> > This way all the item states persisted in cluster node 1 will be
evicted
> > from the cache of the other nodes thus forcing them to take them
from
> > the persistent storage once more on the next first read or write
> > operation.
> >
> > Does this make sense you think?
> 
> I see a couple of issues with your approach:
> 
> simply acquiring the write locks on other cluster nodes in a random
> sequential order
> may lead to a deadlock situation, unless the cluster defines a strict
> order which is
> known to all cluster nodes and locks are always acquired in that
order.
> 
> I'm not sure if evicting the states from the caches will do it's job.
> there might be
> local (and transient) states that are connected to the shared states.
> simply removing
> them from the cache will not work in that case.

Right, I was afraid that removing the state id from shared item state
cache wouldn't be enough.

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. What should I do if the
underlying state does not exist? 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?
			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.

regards
Giota
 
> 
> finally, what happens if the a cluster node crashes while holding
'remote'
> write
> locks on other nodes? will they be released?
> 
> regards
>   marcel


Mime
View raw message