[SERVER-35429] The inner one of nested AutoGetCollectionForReads cannot fall back to take PBWM if the outer one opts out of PBWM Created: 05/Jun/18 Updated: 29/Oct/23 Resolved: 26/Jul/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | 4.0.0 |
| Fix Version/s: | 4.1.2 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Xiangyu Yao (Inactive) | Assignee: | Xiangyu Yao (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Operating System: | ALL |
| Sprint: | Storage NYC 2018-07-30 |
| Participants: |
| Description |
|
For nested AutoGetCollectionForReads, if the outer one already opts out of the PBWM, the inner one could not take the PBWM if there are pending catalog changes, because the ShouldNotConflictWithSecondaryBatchApplicationBlock of the outer one still takes effect. The ticket is just for keeping track of this issue because there might be cases where we have nested AutoGetCollectionForReads and want the inner one to take the PBWM. Currently the inner one will try to take the PBWM (by unsetting ShouldNotConflictWithSecondaryBatchApplicationBlock) and think it succeeds. But the reads actually won't hold the PBWM. We could add an invariant or comments to make a note that ShouldNotConflictWithSecondaryBatchApplicationBlock might not work as expected if AutoGetCollectionForRead is nested. |
| Comments |
| Comment by Githook User [ 26/Jul/18 ] |
|
Author: {'name': 'Xiangyu Yao', 'email': 'xiangyu.yao@mongodb.com', 'username': 'xy24'}Message: |