[SERVER-37677] Shards shouldn't abort local transaction on stale version error if router was stale Created: 19/Oct/18 Updated: 06/Dec/22 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: | Won't Fix | Votes: | 0 |
| Labels: | ShardedTxn:RouterSupport | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Sharding
|
| Participants: |
| Description |
|
As described in the design document for sharded transactions, shards don't need to abort their local transactions on stale version errors if the router was stale, because the shard won't have to refresh its metadata in this case and won't need to take a collection exclusive lock on the collection that triggered the exception. |
| Comments |
| Comment by Randolph Tan [ 23/Oct/18 ] |
|
I don't think it's correct to do this for any write command since it could have aborted the recovery unit the entire transaction. |