Transaction related queries for conflicting transactions ( Coming from a Mysql Innodb Transaction mgmt environment)

Users Dgraph
1

Ref : Releasing distributed transactions in v0.9 - Dgraph Blog

“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 :
1.

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.

2

I am referring to the Dgraph paper while answering these questions.

  1. While your observation can be generally true, there is a fine difference that might need attention. As per the paper:
    "When a transaction requests a
    commit, Zero would check if any of those keys has a commit
    timestamp higher than the start timestamp of the transaction.
    If the condition is met, the transaction is aborted. "

Apart from the Start ts, there is a commit ts in play. So it can potentially mean that when A and B update a key simultaneously, the first one to commit will succeed. In other words, the start Ts alone does not guarantee ordering.

  1. Dgraph will throw a “TxnConflictException”, a conflict exception, as soon as it detects one.

  2. Dgraph reads are linearizable, so yes.

1 Like
3

This paper is one of the best resources on Dgraph . Thank you so much :slight_smile:

1 Like