[SERVER-36300] Audit re-use of operation contexts in mongos for metadata operations Created: 26/Jul/18  Updated: 29/Oct/23  Resolved: 19/Oct/18

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

Type: Task Priority: Major - P3
Reporter: Jack Mulrow Assignee: Jack Mulrow
Resolution: Fixed Votes: 0
Labels: ShardedTxn:RouterSupport
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-36277 Allow mongos to forward txnNumbers th... Closed
Backwards Compatibility: Fully Compatible
Sprint: Sharding 2018-10-22
Participants:

 Description   

A lot of transaction machinery on mongos relies on the operation context to attach transaction options to outgoing requests in the sharding task executor. If mongos re-uses the operation context used to send the client requests to shards to also send metadata operations / refreshes to the config server, it may be attaching transaction options to those requests as well. This could lead to strange behavior, like mongos believing the CSRS is a participant in a transaction, or possibly metadata refreshes being run as single replica set transactions.

The purpose of this ticket is to figure out where mongos can use the same operation context for client requests and other operations, and to decide how to deal with this.

An example is in the batch write path where initializing a ChunkManagerTargeter may involve creating a sharded collection through the config server using the same operation context that will eventually send the batch writes.



 Comments   
Comment by Jack Mulrow [ 19/Oct/18 ]

As of SERVER-37016, the MultiStatementTransactionRequestsSender attaches transaction options instead of the sharding task executor, so the risk described in this ticket is substantially reduced. For instance, the example from the ticket description uses the Shard::runCommand interface, which does use the sharding task executor, but not the new enhanced ARS. As of now, the only places that use this version of the ARS that are not user commands are:

  1. establishCursors
  2. gatherResponses
  3. BatchWriteExec::executeBatch

Of these, none seem to be used in ways that would unintentionally send transaction options, so I'm closing this ticket as resolved.

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