Does JBoss Cache and semaphores

[bruce76]

Hi,

We're using JBoss cache to share data between two servers in a cluster. We would like only one of the servers to operate on data in the cache for certain use cases (in other use cases, we want both nodes to have access at the same time).

Does JBoss cache provide a semaphore mechanism that will enable us to limit the access the cache and prevent race conditions?

Thanks,

Bruce

[manik]

JBoss Cache works on a completely peer based system, no server is given 'preference' over another.

Locking is done on a per instance basis so (based on node locking scheme and isolation level used) only a single thread may access a piece of data at a given time.

When replicating, this integrity is maintained across a cluster (based on replication method selected - REPL_SYNC recommended for what you are trying to achieve) by performing a 2 phase commit at your transaction boundary. This will ensure locks are acquired on remote nodes first (during a prepare phase) before your changes/modifications are allowed to commit.

Still though, any instance in the cluster may make such changes and that instance will ensure data integrity for the transaction.

HTH.

Cheers,
Manik

[dmary]

Hi,

is still exist any solution for this kind of case ?
I'm also have same problem as I'm running a farm of Jboss onto 2 servers, sharing some datas into a jboss cache, and I want in some explicit case, to lock an arraylist for one thread (server 1 or server 2), other thread on same server or the other server cannot access to the ArrayList until the first thread has finished its process.. ???

[jason.greene]

dmary,

I answered your question in the POJO Cache forums:
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4147827#4147827

The short answer, is that we do not yet have support for distributed locking on a node. It is however, on the roadmap. It should be noted that distributed locking negatively impacts scalability, and is not usually needed for most cache use cases. So when we add this feature, it will be selectively enabled (probably per node), and should only be used when you really need it.

If you follow the thread reference there was discussion about possible alternatives (JMS etc).