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