[SERVER-41582] Investigate disallowing DBDirectClient from changing the storage engine ReadSource Created: 07/Jun/19 Updated: 06/Dec/22 Resolved: 05/Oct/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Louis Williams | Assignee: | Backlog - Storage Execution Team |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | groomed | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Storage Execution
|
||||||||
| Participants: | |||||||||
| Description |
|
The fact that DBDirectClient is allowed to change the storage engine snapshot is the cause of many hard-to-reproduce bugs and many problems. DBDirectClient can early-returned in waitForReadConcern, which is already done for snapshot readConcern. Additionally, the logic in AutoGetCollectionForRead allows DBDirectClient to potentially change the storage engine snapshot while another AutoGetCollectionForRead has read from a different snapshot (see We should investigate whether this behavior is actually necessary, and disallow it if possible. |
| Comments |
| Comment by Louis Williams [ 05/Oct/20 ] |
|
As of That change also ensured that DBDirectClient behaves like any external network operation, as that is what callers expect. This means the DBDirectClient is allowed to change the Operation's ReadSource to read at lastApplied if that is what it requires, and I believe that is the correct thing to do. For that reason, I am closing this ticket. |