[ 
https://issues.apache.org/jira/browse/IGNITE-27435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18047387#comment-18047387
 ] 

Denis Chudov commented on IGNITE-27435:
---------------------------------------

On commit partition we may act the same way as we do with FINISHING state on 
coordinator: just wait for final state and then respond.

Please note that transition from COMMITING to ABORTED should be possible in 
case if commit failed

> Improve commit latency for explicit RW transactions
> ---------------------------------------------------
>
>                 Key: IGNITE-27435
>                 URL: https://issues.apache.org/jira/browse/IGNITE-27435
>             Project: Ignite
>          Issue Type: Improvement
>            Reporter: Alexey Scherbakov
>            Priority: Major
>              Labels: ignite-3
>             Fix For: 3.3
>
>
> Currently explicit transaction is committed as soon as all write inflights 
> are completed.
> This adds additional latency before beginning to commit, caused by waiting 
> (see TransactionInflights.ReadWriteTxContext#waitNoInflights).
> This can be optimized in the following way:
> 1. Each inflight addtitionally tracks corresponding key in the tx inflight 
> context. A key is removed from the set as soon as inflight is replicated
> 2. We introduce addtitional persisted tx state: COMMITTING
> 3. The a tx is started to commit, it synchronously replicates COMMITTING 
> state instead of COMMITED. Committing state additionally includes a list of 
> keys (ack list), which are being inflight just before commit starts.
> 4. Tx commit as acked to the user as soon as COMMITTING state is replicated 
> and all inflights are finished. This is "implicit commit".
> 5. As soon as tx is "implicitly committed", COMMITED state is replicated 
> asynchronously. After this, tx is considered "explicitely committed".
> We need changes in write intent resolution logic.
> For coordinator path nothing is changed.
> For commit partition path, if the tx is in COMMITTING state, we need to 
> attempt to resolve tx state by validating successful replication of all keys 
> from the ack list. While resolving the state, the COMMITTED message can be 
> received and processed accordingly.
> If multiple write intents are resolved concurrently, other are waiting for 
> the first request outcome.
> Write intent remains unavailable until tx state is resolved.
> If inflight keys hit a hard limit (defined by some configuration parameter), 
> this optimization is disabled.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to