[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 SERVER-24766, AutoGetCollectionOrViewForRead has a method that relinquishes its locks. This is required to maintain correct statistics: simply destroying the AutoGetCollectionOrViewForRead would cause CurOp to log only the time resolving the view and not include the time actually performing the aggregation on the backing namespace.

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.

Generated at Thu Feb 08 04:07:45 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.