-
Type: Task
-
Resolution: Fixed
-
Priority: Minor - P4
-
Affects Version/s: None
-
Component/s: Replication
-
Fully Compatible
-
v4.2
-
Sharding 2019-08-26, Sharding 2019-09-09
-
49
Currently, if a shard receives a request with a higher transaction number on a session for which it currently has a transaction in prepare, the shard fails the request.
This means currently, the transaction coordinator must wait for a transaction decision to be fully ack'd before returning the decision to the client - otherwise our tests that do back-to-back transactions are racy, because the next transaction statement might arrive at a shard before the shard hears the decision from the coordinator.
It would improve the back-to-back latency of transactions, particularly when there is one "slow" participant, if the coordinator could return the decision to the client as soon as the decision is durable.
This ticket is to enable the coordinator to return the decision as when the decision is durable by making requests with higher transaction numbers block rather than fail.
- is depended on by
-
SERVER-37364 Coordinator should return the decision to the client as soon as the decision is durable
- Closed
- is related to
-
SERVER-40808 Recovering a transaction's outcome should block if the participant is in prepare
- Closed
- related to
-
SERVER-44260 Transaction can conflict with previous transaction on the session if the all committed point is held back
- Closed