[SERVER-28602] Add RecoveryUnit setTimestamp() and selectSnapshot() to storage API Created: 04/Apr/17  Updated: 06/Dec/17  Resolved: 22/Aug/17

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: None
Fix Version/s: 3.5.13

Type: Task Priority: Major - P3
Reporter: Eric Milkie Assignee: Eric Milkie
Resolution: Done Votes: 0
Labels: todo_in_code
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-30472 ReplicationConsistencyMarkers::writeC... Closed
Backwards Compatibility: Fully Compatible
Sprint: Storage 2017-04-17, Storage 2017-05-08, Storage 2017-05-29, Storage 2017-06-19, Storage 2017-07-10, Storage 2017-07-31, Storage 2017-08-21, Storage 2017-09-11
Participants:

 Description   

New function: Supply a timestamp for a transaction
virtual Status RecoveryUnit::setTimestamp(SnapshotName timestamp);

  • This function may only be called in a unit of work. (Cannot set timestamps without an open transaction.)
  • It is presumed that only transactions that perform writes will call this function, to assign timestamps. MongoDB aborts all read transactions anyway, so assigning timestamps for such transactions would have no effect.
  • If this function is called multiple times in a WriteUnitOfWork, the timestamps may only move forward (or stay the same). An error will be returned if setTimestamp() attempts to assign a timestamp that is sooner than a previously assigned timestamp for a transaction.

New function: Use a timestamp to read at a point in time
virtual Status RecoveryUnit::selectSnapshot(SnapshotName timestamp);

  • This function may optionally be called prior to calling getCursor() on a RecordStore.
  • This function could be called again after calling getCursor(); this would be useful to, say, change to a more recent snapshot at query yield time. This is the current behavior of read-concern-majority, for example.
  • This function cannot be called while a transaction is active: invariant(!inATransaction)
  • The data returned from the cursor will reflect data from transactions that have committed with write timestamps up to and including time. If a transaction had multiple timestamps assigned to individual writes, such a transaction could be sliced by the read operation. Slicing is only expected to occur for transactions that were committed by the replication machinery for oplog application.
  • The body of this function will set a member variable for the snapshot time in the RecoveryUnit. At the next begin_transaction, it will use the stored time as the read_timestamp parameter.


 Comments   
Comment by Eric Milkie [ 22/Aug/17 ]

Fixed with 77dc6917428ffad4b9ff2d54d78fa9b225f78a4b

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