"If two concurrently running transactions write to the same data, then one of the commits will fail. It’s up to the user to retry"
What i infer from this is that the user will need to retry the aborted transaction. Can you guys please help me with the following queries :
If transaction A and B are competing for update on the same key, is this always true that the transaction with smaller timestamp will always get committed first.
Reason : If other dbs , i have seen a priority based selection of transaction, hence no definite order
Side effect: The dgraph client ( java here in my case) will make sure the order of transaction is maintained and there is an acceptable gap.
If a transaction gets aborted, there are two ways to deal with it. Just want to understand which one is being followed:
-> The transaction waits for some user defined Transaction wait time out and then aborts
-> There is no waiting but the transaction aborts .
The issue in second approach would be, the user will have to make an informed decision when to retry the transaction next.
If i am performing a read using dgraphClient.newTransaction() , will it always get me the committed data
? The answer is yes here but i am just wanting to shout out this since this is pretty much the crux of my app.