[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:
Related
is related to SERVER-33838 Replace setStashedCursor and hasStash... Closed
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

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