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

["Igor Seliverstov (JIRA)" <ji...@apache.org>]

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

Igor Seliverstov updated IGNITE-10829:
--------------------------------------
    Description: 
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).

  was:
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.


> MVCC TX: Lazy query execution for query enlists.
> ------------------------------------------------
>
>                 Key: IGNITE-10829
>                 URL: https://issues.apache.org/jira/browse/IGNITE-10829
>             Project: Ignite
>          Issue Type: Improvement
>          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)