Uploaded image for project: 'Ignite'
  1. Ignite
  2. IGNITE-17856

RW reads and scans should use timestamp based MVPartitionStorage read and scan operations

    XMLWordPrintableJSON

Details

    • Improvement
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • None
    • 3.0.0-beta1
    • None

    Description

      Motivation

      Tx protocol design assumes that data entry exists in the form of a write intent from the moment the entry is changed within transaction to the moment it is either converted to the regular value or removed during tx cleanup phase.

      Read Only transactions because of their lock-less nature may see such writeIntents (corresponding changes were implemented within IGNITE-17720  and IGNITE-17627) and ...

      ... according to tx design updates so does Read Write transactions.

      Let's clarify this in greater detail:

      • Originally tx finish process firstly converted the write intents into regular values, and only then released the locks. Thus, other RW transactions could never see write intents as they were always waiting for locks to be released.
      • In the current version of the TX IEP, the order has been changed to the opposite: locks are released before write Intents conversion, so that not only a RO but also a RW transactions may see the intents.

      All in all, that means that both read and scan RW operations may use timestamp based reads and scans with a properly distant timestamp in the future.

      Definition of Done

      Cursor<BinaryRow> scan(UUID txId) 

      and

      BinaryRow read(RowId rowId, UUID txId) 

      should be removed.

      PartitionTimestampCursor scan(HybridTimestamp timestamp)  

      and

      ReadResult read(RowId rowId, HybridTimestamp timestamp) 

      should be used instead.

      Implementation notes

      Solution is pretty straight forward

      • Removing deprecated methods along with underneath implementations.
      • Propagating RW reads and scans to timestamp based MvPartitionStorage reads and scans with some sort of HybridTimestamp.MAX_VALUE as a timestamp paramter.
      • Verifying that within RW transactions returned ReadResults contain values with matching txIds (see TxIdMismatchException). That should be guaranteed by locks.

      Attachments

        Issue Links

          Activity

            People

              alapin Alexander Lapin
              alapin Alexander Lapin
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Time Tracking

                  Estimated:
                  Original Estimate - Not Specified
                  Not Specified
                  Remaining:
                  Remaining Estimate - 0h
                  0h
                  Logged:
                  Time Spent - 1h
                  1h