[SERVER-24909] Investigate releasing locks in the constructor of AutoGetCollectionOrViewForRead Created: 05/Jul/16 Updated: 06/Dec/22 Resolved: 10/Jun/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Internal Code |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Kyle Suarez | Assignee: | Backlog - Storage Execution Team |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Storage Execution
|
| Participants: |
| Description |
|
In This unlock method is not in the spirit of RAII and we should investigate whether or not it would be possible to relinquish the database lock in the constructor of AutoGetCollectionOrViewForRead instead if the namespace is a view and not a collection. |
| Comments |
| Comment by Andy Schwerin [ 06/Jul/16 ] |
|
I disagree that an unlock() or dismiss() method is out of the spirit of an RAII object. See, for example, std::unique_lock. However, if a RAII object with the behavior described is useful, please don't call it AutoGetCollectionOrViewForRead, since the AutoGet types typically hold their locks. |