[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:
Backports
Depends
is depended on by SERVER-37364 Coordinator should return the decisio... Closed
Related
related to SERVER-44260 Transaction can conflict with previou... Closed
is related to SERVER-40808 Recovering a transaction's outcome sh... Closed
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: SERVER-38028 Block new transactions on sessions behind prepared transactions

This is a combination backport of two commits:
(cherry picked from commit 59079867e7bba25e1201f50d6e470d7157825f84)
(cherry picked from commit 41b3d7da7c763e304bc8f4056d0d31d200742e0b)
Branch: v4.2
https://github.com/mongodb/mongo/commit/9cfde707ff1eab889301a450ba4e1b3d74abe000

Comment by Githook User [ 05/Sep/19 ]

Author:

{'name': 'Matthew Saltz', 'username': 'saltzm', 'email': 'matthew.saltz@mongodb.com'}

Message: SERVER-38028 Block new transactions on sessions behind prepared transactions
Branch: master
https://github.com/mongodb/mongo/commit/59079867e7bba25e1201f50d6e470d7157825f84

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:

My understanding is that we don't want to document it because we are currently providing a stronger guarantee for w:1 than what is required, and we may weaken the guarantee to what w:1 ordinarily means in the near future.

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 SERVER-40808, since both require machinery to make TransactionParticipant notify waiters when it has finished committing or aborting a transaction.

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.

Generated at Thu Feb 08 04:47:45 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.