[SERVER-37349] Subsequent statements in a transaction should target shards using the global read timestamp Created: 27/Sep/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:GlobalSnapshot
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-37045 Consider not allowing killCursors to ... Closed
Related
related to SERVER-37350 Shards should reject writes in a tran... Closed
Backwards Compatibility: Fully Compatible
Sprint: Sharding 2018-10-08, Sharding 2018-10-22, Sharding 2018-11-05
Participants:

 Description   

Currently, the multi-versioned routing table is only used when selecting a global read timestamp, to verify that the set of shards used to compute the read timestamp matches the set that would be targeted at that timestamp. Now that mongos supports multi statement transactions, subsequent statements should route their requests using the multi-versioned routing table corresponding to the already selected read timestamp.



 Comments   
Comment by Githook User [ 19/Oct/18 ]

Author:

{'name': 'Jack Mulrow', 'email': 'jack.mulrow@mongodb.com', 'username': 'jsmulrow'}

Message: SERVER-37349 Later statements in a transaction should target shards using the global read timestamp
Branch: master
https://github.com/mongodb/mongo/commit/9f363b489585124afa1e26412e19f6728763e1ad

Comment by Githook User [ 13/Oct/18 ]

Author:

{'name': 'Kaloian Manassiev', 'email': 'kaloian.manassiev@mongodb.com', 'username': 'kaloianm'}

Message: SERVER-37349 Ensure that commands with transactions do not use the VersionManager
Branch: master
https://github.com/mongodb/mongo/commit/aa89fef4ac12249077ff8701b465d0b9f733fd2c

Comment by Kaloian Manassiev [ 04/Oct/18 ]

Jack and I spoke and we decided that we will make mongos perform the writeConcern parsing and checking as well, similarly to what mongod does. This logic will be pulled into some common function.

For the CatalogCache interaction with the timestamp selection, we decided that we will pull the routing logic into a separate function, which combines the state of the TransactionRouter and the calls to CatalogCache::getCollectionRoutingInfo to pass the appropriate atClusterTime.

Comment by Kaloian Manassiev [ 02/Oct/18 ]

The CatalogCache is supposed to be the lowest level of code which deals with routing information and I really don't want to make it aware of whether the caller is running in a transaction or not.

Mutating the readConcernArgs decoration on mongos doesn't seem like that bad of an idea, however - do we even need to mutate it? It gets instantiated once per OperationContext and even as part of the same transaction, requests can come on different OperationContexts, so each request already must be instantiating a new ReadConcernArgs object anyways. We should be able to hook into that place and construct the proper ReadConcernArgs.

In this case we will need to make the CatalogCache aware of the ReadConcernArgs, but that seems like a more acceptable dependency.

Comment by Jack Mulrow [ 01/Oct/18 ]

Proposed Implementation:

  1. Get the TransactionRouter decoration from the opCtx in CatalogCache::_getCollectionRoutingInfo and if it exists and has selected an atClusterTime, pass it to _getCollectionRoutingInfoAt here, otherwise continue to pass boost::none.

kaloian.manassiev, what do you think of this approach? It's similar to how we already implicitly pass the atClusterTime from the user's readConcernArgs decoration in CollectionShardingState::getMetadata. I thought about also using the readConcernArgs decoration on mongos, but that would require making the atClusterTime selection process mutate that decoration, which it doesn't currently do.

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