[IGNITE-10829] MVCC TX: Lazy query execution for query enlists.

• Type: Task
• Status: Resolved
• Priority: Major
• Resolution: Won't Fix
• Affects Version/s: 2.7
• Component/s: mvcc
• Assignee: Unassigned
• Reporter: Igor Seliverstov
• Created: 27/Dec/18 09:01
• Updated: 25/Aug/23 08:29
• Resolved: 25/Aug/23 08:29

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).

Issue Links

• is blocked by: IGNITE-9171 Use lazy mode with results pre-fetch
• is caused by: IGNITE-10434 MVCC: Transaction asynchronous rollback bug.