[
https://issues.apache.org/jira/browse/IGNITE-27438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18047275#comment-18047275
]
Stanislav Lukyanov commented on IGNITE-27438:
---------------------------------------------
Isn't this partially mitigated by async ops?
E.g.
{code:java}
v = get(k);
put(k, v + 1);
commit();
{code}
is 3 RTT now but
{code:java}
v = get(k);
putAsync(k, v + 1);
commit();
{code}
is already 2 RTT, isn't it?
With certain network settings (large TCP buffer, NODELAY turned off) `putAsync
+ commit` could even be a single network package.
> 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
> Fix For: 3.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" (unconditional) writes in a
> client's memory (both thin and embedded) until commit.
> 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 (determined on
> commit), improving latency. This shines for colocated use cases.
> Similar optimization works in AI2 and makes it faster in specific scenarios.
> There are also drawbacks:
> 1. We need additional memory to store tx data, so this is applicable only to
> "small" transactions.
> 2. Doesn't work with SQL.
> 3. Adds additional complexity to a client.
> We can consider implementing this optimization only for embedded
> transactions. In this case temporaty data can be stored in a coordinator's
> local storage and work with SQL.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
