[
https://issues.apache.org/jira/browse/IGNITE-10829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-10829:
-------------------------------------
Ignite Flags: (was: Docs Required)
> 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)
