[SERVER-68966] Consider removal of the PlanExecutor::LockPolicy code Created: 18/Aug/22  Updated: 27/Oct/23  Resolved: 23/Aug/22

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Dianna Hohensee (Inactive) Assignee: Backlog - Query Execution
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Query Execution
Participants:

 Description   

During earlier SBE development, I recall issues with the LockPolicy::kLocksInternally policy wherein the GlobalLock was not behaving correctly. I believed the decision was made to not use the internal locking policy, so I was concerned when I saw it in the code still: it isn't clear to me whether or not it's active or inactive (dead code)? If it's used for something else now, perhaps the code documentation or class name can be changed to reflect that?

AutoGetCollection* instances cannot be created and destroyed out of order, in the sense that if AGC-A is created first, in parallel with AGC-B and AGC-C created afterwards, then it must be ensured that AGC-A is destroyed last. This is because the first AGC instance makes a GlobalLock instance that on construction is aware that it was created first and takes ownership of performing work upon destruction.



 Comments   
Comment by Dianna Hohensee (Inactive) [ 23/Aug/22 ]

Storch explained to me that the Classic engine doesn't operate stages in parallel, but rather one at a time, unlike the SBE engine. So there will be one AutoGetCollection* instance at a time for the classic engine. Thus the internal locking policy is OK for classic. Since that's all that's in use, closing this ticket.

Generated at Thu Feb 08 06:12:14 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.