[SERVER-33656] After initial snapshot read, only allow getMores for that txnNumber Created: 05/Mar/18 Updated: 27/Oct/23 Resolved: 23/Mar/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Tess Avitabile (Inactive) | Assignee: | James Wahlin |
| Resolution: | Gone away | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Sprint: | Storage NYC 2018-03-26 | ||||||||
| Participants: | |||||||||
| Description |
|
After an initial snapshot read is run, e.g. {find: "c", readConcern: {level: "snapshot"}, lsid: UUID(...), txnNumber: <txnNumber>}, we must require that any subsequent operation using <txnNumber> is a getMore. |
| Comments |
| Comment by James Wahlin [ 23/Mar/18 ] |
|
This work is no longer required as we will restrict snapshot reads to multi-statement transactions. |
| Comment by Tess Avitabile (Inactive) [ 13/Mar/18 ] |
|
Correct. |
| Comment by Spencer Brody (Inactive) [ 13/Mar/18 ] |
|
To be clear, this is specifically about autocommit:true reads, right? autocommit-false read-only transaction will allow multiple cursors to be open at the same time. |
| Comment by Andy Schwerin [ 08/Mar/18 ] |
|
I see. Thanks all! |
| Comment by James Wahlin [ 07/Mar/18 ] |
|
Restricting snapshot reads to one open cursor also allows us to simplify transaction resource stashing. To support multiple open cursors reflecting different points in times would have meant either allowing for more than one stashed transaction resource set per session, or stashing resources on the client cursor. |
| Comment by Eric Milkie [ 07/Mar/18 ] |
|
I expect if you wanted to run multiple finds in the same snapshot, you could use the multi-statement transaction syntax to achieve that. |
| Comment by Tess Avitabile (Inactive) [ 07/Mar/18 ] |
|
We expect to have one cursor per snapshot read. When that cursor is exhausted/killed, that should abort the transaction for the snapshot read. If we allow multiple simultaneous open cursors on a snapshot read, then we would have to keep the transaction open until all cursors are exhausted/killed. If we allow multiple serial open cursors on a snapshot read, it would be a bit strange because they would have the same txnNumber but not read from the same snapshot. We would also need to decide whether to ban you from starting a multi-document transaction at that txnNumber. I think it is simpler if exhausting/killing the cursor aborts the transaction and the txnNumber cannot be reused. |
| Comment by Andy Schwerin [ 07/Mar/18 ] |
|
Why can't I run another find? |
| Comment by Tess Avitabile (Inactive) [ 05/Mar/18 ] |
|
I don't think we would expect killCursors to use the same txnNumber. Or rather, we wouldn't enforce anything about that because killCursors does not check out the session. |
| Comment by James Wahlin [ 05/Mar/18 ] |
|
Or a killCursors invocation on the open cursor |