[SERVER-34646] Write test for killing cursors opened by a transaction Created: 24/Apr/18 Updated: 29/Oct/23 Resolved: 03/May/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | 4.0.0-rc0 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | William Schultz (Inactive) | Assignee: | Tess Avitabile (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Sprint: | Repl 2018-05-07 |
| Participants: | |
| Story Points: | 4 |
| Description |
|
We want to write a test that makes sure transactions behave correctly when any cursors they have opened get killed. We can test this by starting a transaction that opens a cursor, does some reads, and is then externally killed. We should verify that the transaction is able to continue and commit, even after the cursor was killed. |
| Comments |
| Comment by Githook User [ 03/May/18 ] |
|
Author: {'email': 'tess.avitabile@mongodb.com', 'name': 'Tess Avitabile', 'username': 'tessavitabile'}Message: |
| Comment by Tess Avitabile (Inactive) [ 30/Apr/18 ] |
|
For the local snapshot reads project, we made the choices that (1) aborting a transaction kills all associated cursors, (2) killing a snapshot read cursor aborts the transaction (since it is the only operation in the transaction, and killing the cursor should clean up all resources associated with the read), and (3) killing a cursor in a transaction does not abort the transaction. I think it's the right call that killing a cursor in a transaction does not abort the transaction. The drivers will kill a cursor when it goes out of scope, and it would be unexpected that the transaction would be aborted in that case. |
| Comment by Spencer Brody (Inactive) [ 27/Apr/18 ] |
|
Is the write behavior for the transaction to survive if one of its cursors was explicitly killed? I wonder if that should actually cause the transaction to abort instead... |