[SERVER-81182] Review locking invariants in CollectionCatalog Created: 19/Sep/23 Updated: 06/Nov/23 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Jordi Olivares Provencio | Assignee: | Backlog - Catalog and Routing |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | car-qw | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Assigned Teams: |
Catalog and Routing
|
||||
| Participants: | |||||
| Linked BF Score: | 2 | ||||
| Story Points: | 2 | ||||
| Description |
|
Recently we discovered that there are parts of the codebase that are using the CollectionCatalog without acquiring any locks as part of the operation. This can lead to invalid results being returned if the Catalog is accessed during Rollback and/or Shutdown. In both of those states the catalog gets reset to an empty map so all lookups will fail. If an operation accesses the catalog at that point, the results won't be valid. As part of this ticket we should consider updating the comments in the catalog to reflect the necessity of holding the global lock and adding invariants that check that the lock is held. This should prevent new invalid uses of the class. |
| Comments |
| Comment by Shin Yee Tan [ 19/Sep/23 ] |
|
We want this to just update the comments to be more explicit with our expectations. |