[SERVER-53256] Make a new lock helper to encapsulate DBLock and CollectionLock usage Created: 07/Dec/20 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Dianna Hohensee (Inactive) | Assignee: | Backlog - Storage Execution Team |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | neweng | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Assigned Teams: |
Storage Execution
|
||||||||||||
| Participants: | |||||||||||||
| Description |
|
Lock-free reads makes it so that sharding refresh logic cannot use AutoGetDb or AutoGetCollection helpers because those helpers would throw stale config errors, which would stop the refresh operation to fix the staleness. There are a number of cases already where code takes DBLock followed by CollectionLock, to avoid the additional logic run in the AutoGet* helpers. We could make a new wrapper for these operations, a 'dumb' wrapper as opposed to the 'smart' AutoGet* wrappers. |
| Comments |
| Comment by Connie Chen [ 13/Dec/21 ] |
|
This work should only to be create the wrapper, replacing where we use DBLOck and CollectionLock will require someone more experienced. |