[jira] [Updated] (IGNITE-10829) MVCC TX: Lazy query execution for query enlists.

["Maxim Muzafarov (Jira)" <ji...@apache.org>]

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

Maxim Muzafarov updated IGNITE-10829:
-------------------------------------
    Fix Version/s:     (was: 2.8)
                   2.9

> 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.9
>
>
> 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
(v8.3.4#803005)