[
https://issues.apache.org/jira/browse/IGNITE-7604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16401954#comment-16401954
]
Vladimir Ozerov commented on IGNITE-7604:
-----------------------------------------
[~skalashnikov],
1) DmlStatementsProcessor.TxDmlReducerIterator - let's move it top-level class
2) DmlStatementsProcessor.executeUpdateStatement - what would happen if
{{!plan.isLocalSubquery() == true}}, but query is neither INSERT, nor MERGE?
3) Please make sure to add {{Query}} word to new classes, so that we can
distinguish them from native cache stuff.
4) GridNearTxEnlistFuture.init - what is the point of these manipulations with
lock timeouts?
5) GridNearTxEnlistFuture - дooks like batches has 1-to-1 relation to
MiniFuture, so it makes sense to merge them for the sake of memory efficiency.
We can do that separately.
6) GridNearTxEnlistFuture - "remap" flag is not used
7) Please make sure to fix all warnings
[~gvvinblade], your input is needed for changes in DHT enlist futures.
> 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)
