Remote locks incase of no-transaction support.

[gaprashanth]

The chapter on "Transactions" states that "Infinispan can be configured to use and to participate in JTA compliant transactions. Alternatively, if transaction support is disabled, it is equivalent to using autocommit in JDBC calls, where modifications are potentially replicated after every change (if replication is enabled".

In this case of no transaction where every modification is replicated to the cluster members, what happens if the same key is updated from two different members of the cluster. This may result in race conditions where both the members would be attempting to replicate the changes to the same key from directions. So enablng the transaction is the only alternative to this problem ? is there no locking mechanism without a transaction ?

Can we use deadlock detection without enabling the transaction ?

Basically what does Infinispa recommend to avoid dead lock situations in cases where there is no transaction is enabled ?

[galder.zamarreno]

The concurrent modification of the same key from different nodes will go away when lock reordering is implemented: https://issues.jboss.org/browse/ISPN-1132

I don't think deadlock detection can be enabled when txs are not enabled.

If you're facing these situations, currently the easiest thing to do is back-off and retry after a random time but it's not ideal, hence why we're working on ISPN-1132.

[gaprashanth]

Hi Galder,

Let us assume a data grid having 3 nodes A, B and C and the num_copies is set as 2 so that there is one backup per cache entry in the grid.   Now a key k1 is added from node A, so the grid copies one backup on node B.  Due to expiry, the key k1 is removed after sometime on the nodes. So the next time, it will be re-inserted by the cache client.

Now assume three different threads on the nodes try to access this key k1 on all the nodes simultaneously but find that the key is expired so they try to re-insert the key at the same time on all the 3 nodes.

--> Node A adds key k1 and starts sending updates to its backup on node B

--> Node B adds key k1 and starts sending updates to its backup on node C

--> Node C adds key k1 and starts sending updates to its backup on node A

Can this situation exist and confuse the grid operations as there is only one originl and one backup copy required for the grid. But the actions above may result in copying the key k1 on all the nodes ?

So is this situation possible since we are not enabling any transaction or remote locking in the grid.   How do we avoid this situation ?

=========================

The second basic question is if we miss the configuration tag "<transaction > ......</transaction> " in the configuration, is it equivalent to having no tranaction support but the auto-commit is available ?

Or if we use the "<transaction > ......</transaction> "  tag but doesnt start a tranaction manually like tx.start()   ....tx.commit()  , then is it equivalent to having auto-commit() and this case all the changes are replicated instantly either synchronously or asynchronously based on the falg settings.

[galder.zamarreno]

k1 will hash to one node, and it will be stored in that node and one after that in the hash wheel. No matter where the key is added.

To clarify, all auto-commit is about is about wrapping a non-transactional call within a transaction. That only has effect when the cache is configured with transactions but you don't call tm.begin/tm.commit.

This has nothing to do with changes being replicated immediately or not. Async will do a fire and forget at the JGroups level and sync will wait for responses from other nodes.

[gaprashanth]

Ok this clarifies some part.  I have a related question below.

In the same background of the same key k1 is being updated in two nodes concurrently either with transaction support or not,  please confirm whether the following assumptions are correct:

a) In case of no transaction support,    if k1 is concurrently updated on two nodes,  is there a possibility that both the nodes trying to send updates to each other result in a dead lock situation ?  Can we avoid this situation by having asynchrounous writes ?

b) In the above scenario, is redirecting all the writes to the node which is the owner of the k1 is the solution to avoid deadlocks. If yes, how to determine the owner of the key.

c) In case of transaction enabled with eagerLocking = false,  the same situation of a) is possible ?

d) In case of transaction enabled with eagerLocking = true,   probabaly it is better as there is remote locking in advance and no signs of a deadlock ?

is implementation of lock reordering one shot solution to all these ?

[galder.zamarreno]

a) deadlock can happen cos locks are acquired - async gets rid of them

b) with distribution, it can use consistent hashing, with replication, it can simply choose any node in the cluster, i.e. coordinator

c) yes

d) indeed

lock reordering will help with these scenarios

[gaprashanth]

Thanks for the clarifications. I need some more details on how to determine the owner of the key in case of distribution.   Is it a good idea to take the control to ourself and redirect the requests to that key to the same node.

Using Async - means using putAsync() alone or also we need to enable <aSync>true</aSync> in configuration ?

[galder.zamarreno]

a) the owner(s) can easily be determined using the consistent hash function. Why do you wanna take control yourself? Lock reordering will be implemented very soon.

b) <async /> XML element