2PC question

[nanreh]

Hi there,

The JBoss Cache 2.0.0 FAQ says:

2.2.1 Does JBoss Cache support XA (2PC) transactions now?

No, although it is also on our to do list. Our internal implementation does use a procedure similar to 2PC to coordinate a transaction among different instances, but JBoss Cache is not an XA resource.

I'd like to the best possible guarantee that all the caches in my cluster are in sync all the time. I was hoping to accomplish this with a 2PC and I'm wondering if the above FAQ point means there's a limit to what I can actually accomplish when it comes to distributed 2PC transactions.

I'd like to be able to initiate updates with any member of the cluster and have them move forward (or not) together. I'm using JBoss Transactions in a standalone Java SE environment and at this point I have the caches working in a cluster with synchronous replication. I can run a local transaction on any node and replication happens as expected to the other nodes when that local transaction commits.

I'm having problems when I use the distributed flavor of the JBoss transaction manager and after a few days of debugging I'm beginning to think that my use of the distributed transaction manager is inappropriate given the FAQ note above.

So I'm wondering: should just run a local transaction with REPL_SYNC and let JBoss Cache's "internal procedure similar to 2PC" handle errors that may occur during replication or should I continue looking for an error in my distributed transaction manager configuration?

Any information would be a huge help.

thanks...
frank

[manik]

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.

[girishadat]

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(?)?

[manik]

Pessimistic locking is prone to deadlocks. This is why it is deprecated.