[
https://issues.apache.org/jira/browse/IGNITE-27435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Scherbakov updated IGNITE-27435:
---------------------------------------
Description:
Currently explicit transaction is committed as soon as all write inflights are
completed.
This adds additional "tail" latency before beginning to commit.
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 inglight is replicated
2. We introduce addtitinal 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 tx recovery. When an abandoned write intent is encountered
and tx is in COMMITTING state and corresponding key is in the ack list, we need
to check if it is fully replicated. If no, tx is marked as rolled back.
If inflight keys are too many (defined by some configuration parameter), this
optimization is disabled.
was:
Currently explicit transaction is committed as soon as all write inflights are
completed.
This adds additional "tail" latency before beginning to commit.
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 inglight is replicated
2. We introduce addtitinal 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 tx recovery. When an abandoned write intent is encountered
and tx is in COMMITTING state and corresponding key is in the ack list, we need
to check if it is fully replicated. If no, tx is marked as rolled back.
> 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 "tail" latency before beginning to commit.
> 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 inglight is replicated
> 2. We introduce addtitinal 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 tx recovery. When an abandoned write intent is encountered
> and tx is in COMMITTING state and corresponding key is in the ack list, we
> need to check if it is fully replicated. If no, tx is marked as rolled back.
> If inflight keys are too many (defined by some configuration parameter), this
> optimization is disabled.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
