-
1. Re: Remote locks incase of no-transaction support.
galder.zamarreno Oct 10, 2011 6:06 AM (in response to gaprashanth)1 of 1 people found this helpfulThe 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.
-
2. Re: Remote locks incase of no-transaction support.
gaprashanth Oct 11, 2011 5:24 AM (in response to galder.zamarreno)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.
-
3. Re: Remote locks incase of no-transaction support.
galder.zamarreno Oct 11, 2011 5:51 AM (in response to gaprashanth)1 of 1 people found this helpfulk1 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.
-
4. Re: Remote locks incase of no-transaction support.
gaprashanth Oct 12, 2011 8:53 AM (in response to galder.zamarreno)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 ?
-
5. Re: Remote locks incase of no-transaction support.
galder.zamarreno Oct 14, 2011 3:03 AM (in response to gaprashanth)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
-
6. Re: Remote locks incase of no-transaction support.
gaprashanth Oct 14, 2011 4:55 AM (in response to galder.zamarreno)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 ?
-
7. Re: Remote locks incase of no-transaction support.
galder.zamarreno Oct 18, 2011 3:34 AM (in response to gaprashanth)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