[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: |
|
||||||||||||||||
| 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: |
| Comment by Githook User [ 13/Oct/18 ] |
|
Author: {'name': 'Kaloian Manassiev', 'email': 'kaloian.manassiev@mongodb.com', 'username': 'kaloianm'}Message: |
| 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:
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. |