[
https://issues.apache.org/jira/browse/IGNITE-27438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Scherbakov updated IGNITE-27438:
---------------------------------------
Description:
Currently each expicit tx operation is executed on a primary replica and adds
an RTT to transaction latency for each operation.
This can be optimized by buffering "blind" writes (unconditinal puts) on a tx
coordinator until commit.
Similar optimization exists in AI3.
This gives several benefits:
1. Only read operation causes network round trips.
2. Subsequent reads and writes can be served locally. For example
{code:java}
int val = table.get(tx, key); // Enlists on primary replica and buffered locally
table.put(tx, key, val + 1);
int val2 = table.get(tx, key);
{code}
will produce only one RT.
3. Single partition transactions can be committed in one phase, greatly
improving latency.
There are also drawbacks:
1. We need additionaly memory to buffer tuples: the optimization is applicable
to only small transactions.
2. Mixed KV + SQL case stops working: only KV transactions are applicable.
was:
Currently each expicit tx operation is executed on a primary replica and adds
an RTT to transaction latency for each operation.
This can be optimized by buffering "blind" writes (unconditinal puts) on a tx
coordinator until commit.
Similar optimization exists in AI3.
This gives several benefits:
1. Only read operation causes network round trips.
2. Subsequent reads and writes can be served locally. For example
{code:java}
int val = table.get(tx, key); // Enlists on primary replica
table.put(tx, key, val + 1);
int val2 = table.get(tx, key);
{code}
will produce only one RT.
3. Single partition transactions can be committed in one phase, greatly
improving latency.
There are also drawbacks:
1. We need additionaly memory to buffer tuples: the optimization is applicable
to only small transactions.
2. Mixed KV + SQL case stops working: only KV transactions are applicable.
> Delay writes until expicit transaction commit
> ---------------------------------------------
>
> Key: IGNITE-27438
> URL: https://issues.apache.org/jira/browse/IGNITE-27438
> Project: Ignite
> Issue Type: Improvement
> Affects Versions: 3.3
> Reporter: Alexey Scherbakov
> Priority: Major
> Labels: ignite-3
>
> Currently each expicit tx operation is executed on a primary replica and adds
> an RTT to transaction latency for each operation.
> This can be optimized by buffering "blind" writes (unconditinal puts) on a tx
> coordinator until commit.
> Similar optimization exists in AI3.
> This gives several benefits:
> 1. Only read operation causes network round trips.
> 2. Subsequent reads and writes can be served locally. For example
> {code:java}
> int val = table.get(tx, key); // Enlists on primary replica and buffered
> locally
> table.put(tx, key, val + 1);
> int val2 = table.get(tx, key);
> {code}
> will produce only one RT.
> 3. Single partition transactions can be committed in one phase, greatly
> improving latency.
> There are also drawbacks:
> 1. We need additionaly memory to buffer tuples: the optimization is
> applicable to only small transactions.
> 2. Mixed KV + SQL case stops working: only KV transactions are applicable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
