[
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.
was:Implement lazy query execution using semantic goes from IGNITE-9171.
> 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.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
