[SERVER-48939] Make reads call MigratingTenantAccessBlocker::checkIfCanReadOrBlock Created: 18/Jun/20 Updated: 29/Oct/23 Resolved: 23/Jul/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 4.7.0 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Esha Maharishi (Inactive) | Assignee: | Cheahuychou Mao |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | pm-1791_milestone-A | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Participants: | |||||||||
| Description |
|
Reads should call checkIfCanReadOrBlock after waiting for readConcern, in particular after waiting for their clusterTime to be reached (and therefore waiting for all oplog holes earlier than that clusterTime to be filled). checkIfCanReadOrBlock should not be called under any locks, particularly under database or collection locks. It would be nice if this can be added to the service entry point, but a fallback is to add it to every read command (i.e., every command that can take a readConcern). This ticket should also test that all reads with clusterTime > the blockTimestamp block if the "start blocking" write has occurred. |
| Comments |
| Comment by Githook User [ 23/Jul/20 ] |
|
Author: {'name': 'Cheahuychou Mao', 'email': 'cheahuychou.mao@mongodb.com', 'username': 'cheahuychou'}Message: |