The limitation implied in the statement is based on 2 things:
1) We don't acquire distributed locks as methods are invoked. So, node1 may broadcast a prepare on /a/b/c and node2 may do so as well at the same time. Both txs on both nodes will fail as both prepares will fail.
2) The other limitation is that even after broadcasting a successful prepare and then following up with a successful commit, if for some reason the commit does not reach a network node (e.g., partial network failure) but reaches other nodes, there is no way to recover consistently from this. If you use SyncCommitPhase = true in your configuration, at least the originating node will throw an exception if everyone in the cluster does not respond with an ack after successful commit. Depending on your app, you can handle recovery manually at this stage.
Are these limitations overcame in the latest version of JBC?
I am using JBoss Cache 3 with JBoss TS 4.6. I tried using jts version of JBoss Transactions and put an implementation of TransactionManagerLookup to pass it to JBC. When used with PESSIMISTIC locking, with REPEATABLE_READ isolation level (as per my knowledge, PESSIMISTIC does not consider the isolation level...???). I am able to get lock on the proxy of same objects in cache on two different nodes simultaneously, which is not required/expected. And on commit, both the transactions moves to deadlock, and the first one, which is timed out first, fails and the second one succeeds...! It was OK, if the first one succeeds... But what I expect is, the second transaction locks at get object itself, if T1 is not ended, since this is pessimistic locking...
Is there any solution for this problem(?)?
Pessimistic locking is prone to deadlocks. This is why it is deprecated.