[
https://issues.apache.org/jira/browse/IGNITE-7604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Kalashnikov updated IGNITE-7604:
---------------------------------------
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.
was:Allow DML operations with reducer
> SQL TX: Allow DML operations with reducer
> -----------------------------------------
>
> Key: IGNITE-7604
> URL: https://issues.apache.org/jira/browse/IGNITE-7604
> Project: Ignite
> Issue Type: Task
> Components: sql
> Reporter: Igor Seliverstov
> Assignee: Sergey Kalashnikov
> Priority: Major
>
> 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.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
