[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: |
|
||||||||||||||||
| 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 |
| Comment by Esha Maharishi (Inactive) [ 05/Nov/18 ] |
|
renctan, this has gone away since we introduced the MultiStatementTransactionRequestsSender, right? |