[SERVER-36277] Allow mongos to forward txnNumbers through the sharding task executor Created: 25/Jul/18  Updated: 27/Oct/23  Resolved: 05/Mar/19

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Jack Mulrow Assignee: [DO NOT USE] Backlog - Sharding Team
Resolution: Gone away Votes: 0
Labels: ShardedTxn:RouterSupport
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-35829 Make router TransactionParticipant a... Closed
related to SERVER-36300 Audit re-use of operation contexts in... Closed
is related to SERVER-36260 Mongos should reject commands that ar... Closed
Assigned Teams:
Sharding
Participants:

 Description   

Currently, mongos can't attach the txnNumber from a request's operation context in the sharding_task_executor (like it does with the session id) because it can re-use the same operation context that sends the client's actual request to send metadata operations to the config server (e.g. implicitly creating a sharded collection through the ChunkManagerTargeter). If this could be resolved, mongos could blindly forward txnNumbers to mongod and let mongod validate them, instead of needing to do it itself.



 Comments   
Comment by Randolph Tan [ 05/Nov/18 ]

Just talked with jack.mulrow and this is still an issue today. The problem is that mongos would sometimes fail to propagate the txnNumber from the original request to the shard, so commands that are originally not allowed will now become allowed. This could possibly be resolved by SERVER-36260.

Comment by Esha Maharishi (Inactive) [ 05/Nov/18 ]

renctan, this has gone away since we introduced the MultiStatementTransactionRequestsSender, right?

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