[jira] [Commented] (IGNITE-7604) SQL TX: Allow DML operations with reducer

["Vladimir Ozerov (JIRA)" <ji...@apache.org>]

    [ 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)