TransactionMode.SERIALIZABLE_READ_WRITE and transaction conflicts.

[oleg68]

I have a table with two columnts: id and cnt. There is a row (1, 0).

My (java) application:

1. Begins a transaction (Session.beginTransaction(TransactionMode.SERIALIZABLE_READ_WRITE))
2. selects the old value of cnt with session.executeDataQuery
3. Makes some processing
4. calculates the new value of cnt as oldcnt + 1
5. updates the row with session.executeDataQuery
6. commits the transaction

When two application instances run sequentionally, the row becomes (1, 2).

But when two application instances run at the same time, sometimes the row rests (1, 1). Does it correspond TransactionMode.SERIALIZABLE_READ_WRITE semantics?

Some other rdbms have 'select for update' for this case. Another ones detect the conflict during the commit stage and throw a special exception, so the application can repeat the transaction.

What is a correct way of protection against such conflicts in ydb?

[oleg68]

I found the reason: my test application uses CompletableFuture chains.

But the problem is that almost all ydb completable futures (returned by Session.executeDataQuery, Transaction.commit()) do not throw Exceptions. So the programmer always must check the status with the expect method.