[SERVER-36588] Handle non-locking killCursors in transactions Created: 10/Aug/18  Updated: 06/Dec/22

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

Type: Task Priority: Major - P3
Reporter: Tess Avitabile (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   

In MongoDB 4.0, when the killCursors command is issued as part of a transaction, it checks out the session and uses the same locker as the transaction. This is important because killCursors must take locks, so if it used a different locker, then it could block behind a DDL operation that is blocked behind the transaction, preventing the killCursors (and the transaction that it is part of) from making progress.

When all cursors are globally managed, killCursors will no longer need to take locks. This means it no longer needs to use the same locker as the transaction. It also means that killCursors will trigger an invariant if it is the first operation in the transaction, since we expect the locker to be non-empty when we release its WT ticket and stash transaction resources.

We have a few options for how to address this. We could ban killCursors from being the first statement in a transaction. We could ban killCursors in transactions entirely (though this would require drivers changes). Or we could allow transactions to stash an empty locker.



 Comments   
Comment by Tess Avitabile (Inactive) [ 07/Feb/19 ]

Correct, this is an optional simplification. killCursors could now skip session checkout (by removing it from this list) and we could remove the restriction that killCursors must not be the first statement in a transaction.  This is not very important.

Comment by David Storch [ 07/Feb/19 ]

tess.avitabile now that all cursors are globally managed, we should re-prioritize this issue. Can you elaborate on whether this is still important? If I understand correctly, this is an optional simplification that we could make in the transactions code now that killCursors does not acquire a lock.

Comment by Tess Avitabile (Inactive) [ 24/Aug/18 ]

I did not realize, but we now always take a lock at the start of a transaction, so there may not be a problem.

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