[SERVER-68872] runAggregate should be refactored so that locking isn't so confusing Created: 16/Aug/22  Updated: 05/Dec/22

Status: Backlog
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: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Query Execution
Participants:

 Description   

My particular angle of motivation on the refactor is from SERVER-67424 wherein I encountered the following problem:

"It appears that we modify read concern settings (prepared conflict) in DocumentSourceWriter. The problem with this is that if the high level code has a AutoGetLockFree*, we've already got a storage snapshot open: read concern is normally manipulated in the AutoGet* or earlier layers. It works today because we happen not to hold AutoGet* across runAggregate's use of DocumentSourceWriter. I was trying to hold locks across this, to hold a lock across registration of CursorManager::registerCursor for concurrency control with replication rollback."

Locking uncertainty in runAggregate hinders development: it's very confusing.


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