[SERVER-33367] Enforce a cursor is iterated in a transaction/session iff it was created in that transaction/session Created: 16/Feb/18 Updated: 29/Oct/23 Resolved: 06/Mar/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | 3.7.3 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | James Wahlin | Assignee: | Tess Avitabile (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||
| Sprint: | Storage NYC 2018-03-12 | ||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||
| Description |
|
If a cursor was created in a transaction (or snapshot read), it should not be allowed to getMore it outside of that transaction. If a cursor was not created in a transaction (or snapshot read), it should not be allowed to getMore it inside a transaction. Additionally, a cursor should be iterated in a session iff it was created in that session. |
| Comments |
| Comment by Tess Avitabile (Inactive) [ 11/Oct/18 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
This might be risky because not all versions of 3.6 have the fix inĀ | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Blake Oler [ 11/Oct/18 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Do we want to backport the getMore LSID cursor verification to 3.6? I can backport the "guarantee full LSID" code from | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Tess Avitabile (Inactive) [ 06/Mar/18 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I do not expect there to be Drivers changes, since the Drivers should always attach the lsid/txnNumber of the originating command to the getMore, but I want to inform the Drivers that this is now enforced on the Server. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Githook User [ 06/Mar/18 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Author: {'email': 'tess.avitabile@mongodb.com', 'name': 'Tess Avitabile', 'username': 'tessavitabile'}Message: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Tess Avitabile (Inactive) [ 27/Feb/18 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Per in-person discussion, the work done for txnNumber integrity will also cover local snapshot reads. This ticket should cover getMores of transaction cursors from outside the transaction and getMores non-transaction cursors from inside a transaction in a general way that covers both local snapshot reads and multi-statement transactions. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Tess Avitabile (Inactive) [ 27/Feb/18 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
spencer, just to check, will the work you do for ensuring txnNumber does not move backward and statement IDs are not repeated also cover local snapshot reads, or only multistatement transactions? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Tess Avitabile (Inactive) [ 27/Feb/18 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
In the case where we create a snapshot cursor then exhaust it outside of the transaction, I think the only problem is that we don't clean up transaction state. Maybe we don't care. In the case where we create a normal cursor then iterate it inside a transaction (and we have stashed transaction state), we hit the following invariant:
At the very least we will need to address this issue. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Spencer Brody (Inactive) [ 26/Feb/18 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
We plan on erroring if txnNumber goes backwards, or if we see a stmtId we've already seen for the current txnNumber. We don't currently have any plans to do any cursor-specific checks. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Tess Avitabile (Inactive) [ 26/Feb/18 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
spencer, do you have any similar work planned for multi statement transactions? For example, erroring if a getMore is received with the txnNumber of the currently open multi-statement transaction, but with a cursor ID of a cursor not created as part of the transaction? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Tess Avitabile (Inactive) [ 16/Feb/18 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
We should also ban running a getMore outside of a transaction that is on a snapshot cursor. |