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

Add transaction id to commitWrite and abortWrite methods of Storage

    XMLWordPrintableJSON

Details

    • Task
    • Status: Open
    • Major
    • Resolution: Unresolved
    • None
    • None
    • None
    • Docs Required, Release Notes Required

    Description

      Currently both commitWrite and abortWrite from MvPartitionStorage are expected to be called from the transaction that made the changes.
       
      This is how they look like:

          /**
           * Aborts a pending update of the ongoing uncommitted transaction. Invoked during rollback.
           *
           * @param rowId Row id.
           * @return Previous uncommitted row version associated with the row id.
           * @throws StorageException If failed to write data to the storage.
           */
          @Nullable BinaryRow abortWrite(RowId rowId) throws StorageException;
      

      and

          /**
           * Commits a pending update of the ongoing transaction. Invoked during commit. Committed value will be versioned by the given timestamp.
           *
           * @param rowId Row id.
           * @param timestamp Timestamp to associate with committed value.
           * @throws StorageException If failed to write data to the storage.
           */
          void commitWrite(RowId rowId, HybridTimestamp timestamp) throws StorageException;
      

      If any of these methods are to be called asynchronously, they will need special handling to avoid commiting write intents from a mismatching transaction.

      Imaging the case

      • Transaction txrw1 creates a write intent for row1. txrw1 is committed but write intents are not finalized.
      • Both new transactions txrw2 and txro3 see write intent for the same row, resolve it and want to do a cleanup in the background.
      • the background task from txrw2 runs first, commits that write intent. Then txrw2 adds its own write intent for row1
      • now the background task from txro3 runs. Should it silently commit the same row, it would write a write intent from a running transaction txrw2, not from the committed txrw1.
        Right now we have to do another data read prior to committing to avoid the described case.

      Definition of Done
      Both commitWrite and abortWrite should be extended with a new parameter transaction id (UUID txId).
      If the provided transaction id does not match the one from the row's write intent, the commit/abort operation should not run.

      Implementation details
      There are two options what to do if the passed transaction id does not match the one from the write intent:

      • either throw TxIdMismatchException
      • or return false from the method indicating that it did nothing.
        The decision to be made while working on this task.

      Attachments

        Issue Links

          Activity

            People

              Unassigned Unassigned
              ksizov  Kirill Sizov
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated: