[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. |