TreeCache data integrity across cluster

[magicmac]

Hey,

These are my first steps with JBossCache, but it seems like I already face some basic problem

Simple example:
2-node cluster, each with instance of treeCache. Out of AS.
REPL_SYNC, locking PESSIMISTIC, state is replicated on startup.

run the following algorithm on to machines concurrently:

Machine A:

for i=0..100
counter = tree.get(fqn,counter_key,counter_value);
counter++;
tree.set(fqn,counter_key);

Machine B:
exactly the same code

The result: of course counter is <<200 since we lack synchronization of given get-put blocks.
As I already found out there is no cluster-wide lock. The locks I can explicitly acquire on node are not broadcasted.

It seems that I need transactions for that.

Machine A:
for i=0..100
beginDummyTransaction
counter = tree.get(fqn,counter_key,counter_value);
counter++;
tree.put(fqn,counter_key);
commitDummyTransaction

Machine B: same as A.

Unfortunatelly with such approach I get TimeoutExceptions as B for some reason cant aquire write-lock (or A).
The commit is a 2PC and from logs it really seems to work sync. The lock-aquiring-problem occurs when the other transaction tries to commit.

Is there any way of providing 100% integity of data when heavy updates occur in multiple cluster nodes? In my particular case, I need to buffer the stats of user buisness-logic operations of very-heavy accessed web portal. Such updates occur up to 100/sec per machine. Since there is no explicit cluster-wide locking how can I achieve it? Is there a way of aquiring write-lock at the begining of transaction (on read) and force other readers to wait till this lock is realesed on commit ? Or something like that/simulation of critical section.

I may not express myself clearly here so if you need any more info let me know.

Thanks for any light
M.

[manik]

No, we don't have an explicit mechanism of obtaining a cluster-wide lock.

A local lock is obtained on method invocation and is maintained till your transaction ends (commits or rolls back).

Locks on remote instances are obtained and released during the 2-phase commit. (The prepare call attempts to acquire locks and updates data; the commit phase releases locks)

If the prepare phase cannot acquire the remote locks it needs within the given time (specified by the LockAcquisitionTimeout attribute) you see TimeoutExceptions.

You could also see TimeoutExceptions when trying to acquire the local lock if you have a lot of concurrent threads accessing the data.

You may want to try OPTIMISTIC locking, which greatly improves concurrency - at the cost of the occasional transaction failure due to validation clashes when updating concurrently accessed data.

Cheers,
Manik