[SERVER-67424] Seek and destroy open storage cursors saved in the CursorManager across commands on rollback/shutdown (storage engine closure) Created: 21/Jun/22  Updated: 06/Dec/22

Status: Open
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 - Storage Execution Team
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-68047 Turn project flags into feature flags Open
Related
is related to SERVER-69143 CursorManager no longer needs to hand... Open
is related to SERVER-69506 An InterruptibleLockGuard should be p... Backlog
is related to SERVER-69406 Place InterruptibleLockGuards in the ... Closed
Assigned Teams:
Storage Execution
Sprint: Execution Team 2022-06-27, Execution Team 2022-07-11, Execution Team 2022-08-08, Execution Team 2022-08-22, Execution Team 2022-09-05, Execution Team 2022-09-19
Participants:

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

This task is being put on hold, along with the project. The latest impediment to solving this ticket's problem is that there exists a category of operations that are not interrupt by rollback, which in theory could take storage cursors unassociated with the CursorManager.

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

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.

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