Description
The following protocol is proposed for DML request with non-trivial reduce step within a transaction.
1. The SQL select part is deduced from a DML request and is split to form two-step map/reduce request.
2. Map query requests are sent to data nodes which execute them locally.
3. Resulting data pages are sent to originating node (reducer), which accumulates them.
4. Originating node performs reduce step on data received from map nodes and
forms batches of updates to apply to target table.
5. Lock requests containing delta updates are mapped and sent to data nodes storing the corresponding keys.
6. Lock acks are received at originating node and accumulated there, producing the total update counter.
Note that no locks are acquired when map requests are processed.
This is consistent with what Oracle and PostgreSQL do (but not MySQL!) with respect to locks within complex DML statements.
The Oracle docs (https://docs.oracle.com/cd/B28359_01/server.111/b28318/consist.htm#CNCPT1351) specifically states:
The transaction that contains a DML statement does not need to acquire row locks on any rows selected by a subquery or an implicit query, such as a query in a WHERE clause. A subquery or implicit query in a DML statement is guaranteed to be consistent as of the start of the query and does not see the effects of the DML statement it is part of.
Attachments
Issue Links
- blocks
-
IGNITE-7973 TX SQL: plain INSERT should not be broadcasted to all data nodes
-
- Resolved
-
- Is contained by
-
IGNITE-4191 SQL: support transactions
-
- Resolved
-
- is duplicated by
-
-
- Resolved
-