Description

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.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 be determined only on preparation stage

— at the same time, if a read-view transaction does DML statements, they will nevertheless be tracked, which is impossible without violating our tuple story invariants (see #7239).

Proposal

1. Conflict read-view transactions on attempt to perform DML statements immediately.
2. Make conflicted transactions unconditionally throw Aborted by conflict error on any CRUD operations until they are either rolled back or committed.