box: fix transaction "read-view" and "conflicted" states#7252
Merged
locker merged 1 commit intotarantool:masterfrom Jun 16, 2022
Merged
box: fix transaction "read-view" and "conflicted" states#7252locker merged 1 commit intotarantool:masterfrom
locker merged 1 commit intotarantool:masterfrom
Conversation
202b091 to
cfd1d03
Compare
cfd1d03 to
a129984
Compare
locker
requested changes
Jun 10, 2022
Currently, there is a fundamental logical inconsistency with read-view and conflicted states of transactions. Conflicted transactions see all prepared changes (e.g., tarantool#7238), because they are handled differently than read-view ones. At the same time, one does not know the state of the transaction until `box.commit` is called. A similar problem arises with read-view transactions: if such transactions do any DML statements, they are de-facto conflicted, but this will only be determined at preparation stage: https://github.com/tarantool/tarantool/blob/79245573dabf3c1eb4eb904fd80ee84270360476/src/box/txn.c#L1006-L1013 Fix this inconsistency by the following changes: 1. Conflict "read-view" transactions on attempt to perform DML statements immediately — guarantee this with an assertion at preparation stage. 2. Make conflicted transactions unconditionally throw "Transaction has been aborted by conflict" error on any CRUD operations (including read-only ones) until they are either rolled back (which will return no error) or committed (which will return the same error). Closes tarantool#7238 Closes tarantool#7239 Closes tarantool#7240 @TarantoolBot document Title: new behaviour of "conflicted" transactions "Conflicted" transactions now return "Transaction aborted by conflicted" error on any CRUD operations (including read-only ones), until they are either rolled back (which will return no error) or committed (which will return the same error).
a129984 to
64b18c1
Compare
locker
approved these changes
Jun 16, 2022
Member
|
@alyapunov @kyukhin Do we need to backport this fix to 2.10? This is a bug fix, but it introduces a potentially breaking change: conflicting transactions raise errors right on DML/DQL, not on commit, as they used to. None of the tickets it closes has a milestone... |
Member
|
According to @alyapunov it's okay to backport this fix to 2.10. PMs don't mind. Backported to 2.10. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Currently, there is a fundamental logical inconsistency with read-view and
conflicted states of transactions.
Conflicted transactions see all prepared changes (e.g., #7238), because
they are handled differently than read-view ones. At the same time, one
does not know the state of the transaction until
box.commitis called.A similar problem arises with read-view transactions: if such transactions
do any DML statements, they are de-facto conflicted, but this will only be
determined at preparation stage:
tarantool/src/box/txn.c
Lines 1006 to 1013 in 7924557
Fix this inconsistency by the following changes:
immediately — guarantee this with an assertion at preparation stage.
aborted by conflict" error on any CRUD operations (including read-only
ones) until they are either rolled back (which will return no error) or
committed (which will return the same error).
Closes #7238
Closes #7239
Closes #7240