[
https://issues.apache.org/jira/browse/IGNITE-7604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16406167#comment-16406167
]
Sergey Kalashnikov commented on IGNITE-7604:
--------------------------------------------
[~vozerov],
p.1,3,5,6,7) fixed.
p.2) In that case, the query will be processed with current one-step "query
enlist" protocol.
In fact, 'isLocSubqry' is always false for anything other than INSERT, MERGE or
BULK_LOAD (the latter being a mistake I guess).
Thus, if we remove the check for mode equal to INSERT or MERGE here, the UPDATE
and DELETE queries will always be processed with new "map/reduce + batch"
protocol, which is incorrect.
p.4) First we check that transaction context has a timeout handler installed(in
absense of current operation it is a GridNearTxLocal own handler that would
initiate a rollback).
We need to replace current "idle" handler with our own handler for the duration
of our operation. So we call remove tx.removeTimeoutHandler().
If we fail to remove old handler, it means that tx is already timed out and we
must arrange to be notified when transaction is rolled back in order to fail
our own future.
If removal was successful, we install our own handler.
When our future is complete we restore the GridNearTxLocal's handler with a
call to tx.addTimeoutHandler().
> 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)
