[SERVER-38028] Participant with prepared transaction on session should block request for higher txn number on session rather than failing the new request Created: 08/Nov/18 Updated: 29/Oct/23 Resolved: 06/Sep/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | 4.3.1, 4.2.4 |
| Type: | Task | Priority: | Minor - P4 |
| Reporter: | Esha Maharishi (Inactive) | Assignee: | Matthew Saltz (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | ShardedTxn:FutureOptimizations | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||
| Backport Requested: |
v4.2
|
||||||||||||||||||||||||
| Sprint: | Sharding 2019-08-26, Sharding 2019-09-09 | ||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||
| Linked BF Score: | 49 | ||||||||||||||||||||||||
| Description |
|
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. |
| Comments |
| Comment by Githook User [ 27/Feb/20 ] |
|
Author: {'name': 'Matthew Saltz', 'username': 'saltzm', 'email': 'matthew.saltz@mongodb.com'}Message: This is a combination backport of two commits: |
| Comment by Githook User [ 05/Sep/19 ] |
|
Author: {'name': 'Matthew Saltz', 'username': 'saltzm', 'email': 'matthew.saltz@mongodb.com'}Message: |
| Comment by Esha Maharishi (Inactive) [ 12/Aug/19 ] |
|
As matthew.saltz found on BF-14027, even though the coordinator shard currently waits for all acks before returning an answer to the client, a client can hit this issue if the client recovers a decision using the recovery token, because a recovery shard does not wait for acks before returning an answer. In fact, the recovery shard cannot be made to wait for acks, since the recovery shard (the first write participant) is not always the same as the coordinator shard (the first participant). (The recovery shard must be a write participant because of the read-only optimizations.) |
| Comment by Judah Schvimer [ 21/May/19 ] |
|
That could make sense. I'll leave it up to Aly if we want to mention that we're currently not giving w:1 behavior. |
| Comment by Esha Maharishi (Inactive) [ 21/May/19 ] |
|
judah.schvimer, do you think so? I commented this on HELP-9592:
|
| Comment by Judah Schvimer [ 21/May/19 ] |
|
We should make sure to document this. CC alyson.cabral |
| Comment by Esha Maharishi (Inactive) [ 21/May/19 ] |
|
judah.schvimer they will always be getting writeConcern majority (that is, the transaction's decision, once returned to the client, will never be rolled back). |
| Comment by Judah Schvimer [ 21/May/19 ] |
|
Is this only an optimization? Or are we not respecting the user's writeConcern if we do not do this for 4.2.0? |
| Comment by Esha Maharishi (Inactive) [ 24/Apr/19 ] |
|
Marked as related to |
| Comment by Judah Schvimer [ 14/Jan/19 ] |
|
We're postponing this until prepare is fully correct and tested. |
| Comment by Tess Avitabile (Inactive) [ 08/Nov/18 ] |
|
This would also allow us to respect the user writeConcern and return to the client as soon as the decision is written with the user writeConcern. |