ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vladimir Ozerov (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (IGNITE-10829) MVCC TX: Lazy query execution for query enlists.
Date Mon, 11 Mar 2019 07:40:00 GMT

     [ https://issues.apache.org/jira/browse/IGNITE-10829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Vladimir Ozerov updated IGNITE-10829:
-------------------------------------
    Issue Type: Task  (was: Improvement)

> MVCC TX: Lazy query execution for query enlists.
> ------------------------------------------------
>
>                 Key: IGNITE-10829
>                 URL: https://issues.apache.org/jira/browse/IGNITE-10829
>             Project: Ignite
>          Issue Type: Task
>          Components: mvcc
>    Affects Versions: 2.7
>            Reporter: Igor Seliverstov
>            Priority: Major
>             Fix For: 2.8
>
>
> Running query enlist operations (GridNearTxQueryEnlistFuture) we put query execution
to data nodes, such execution runs a local select (GridDhtTxQueryEnlistFuture), gets a cursor
and executes write operation for each select result row.
> The main difficult starts when we cannot execute whole operation at once (due to lock
conflict or backup message queue overflow). Such case we break iteration and save a context
(detach H2 connection for further exclusive usage and save current position in cursor). There
is no issue since in non-lazy mode the cursor internally have a list of all needed entries
and doesn't hold any resources but in lazy mode we may face two issues:
> 1) Schema change in between of iteration
> 2) Possible starvation because of heavy time consuming operations in cache pool, which
used by default for operation continuation. 
> As soon as IGNITE-9171 is implemented, possible lazy execution is had to be taken into
consideration. This mean:
> 1) before braking iteration we need to release all holding shared locks on on being iterated
tables.
> 2) before continue iteration we need to acquire shared locks on all needed tables and
check the schema wasn't changed in between locks were acquired.
> 3) the operation should be continued in the same pool it was started to prevent possible
starvation of concurrent cache operations (See IGNITE-10597).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message