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 Mon, 08 May 2006 09:52:37 GMT
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?

> -----Original Message-----
> From: Marcel Reutegger [mailto:marcel.reutegger@gmx.net]
> Sent: Wednesday, May 03, 2006 5:12 PM
> To: dev@jackrabbit.apache.org
> Subject: Re: jackrabbit & clustering
> 
> Giota Karadimitriou wrote:
> > another idea would be that maybe I could send the item states
> > from the shared item state manager of one node to the shared item
state
> > managers of other nodes and validate their cache using the public
> > available methods "stateCreated/stateDiscarded/stateModified".
> >
> > The question is whether this would suffice (sharing and revalidating
the
> > state items among shareditemstatemanagers)or more things are needed
to
> > ensure integrity.
> 
> as long as you can ensure that a cluster node does not store changes
> that conflict with another concurrently running store operation on
> another cluster node you should be fine. as I mentioned before I think
> you have to use some sort of distributed locking on the level of the
> different SharedISM in the cluster to ensure consistency. e.g. some
sort
> of a distributed variant of the read-write lock in the SharedISM.
> 
> regards
>   marcel


Mime
View raw message