Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-14090

XA START must be WITH CONSISTENT SNAPSHOT

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: 5.5, 10.0, 10.1, 10.2, 10.3
    • Fix Version/s: 10.2, 10.3, 10.4
    • Component/s: XA
    • Labels:

      Description

      Normally, InnoDB creates transaction read views lazily, on the first access to an InnoDB table, in row_search_for_mysql() or row_search_mvcc().

      There is a special statement

      START TRANSACTION WITH CONSISTENT SNAPSHOT;
      

      that immediately creates a read view, by invoking

      	innobase_hton->start_consistent_snapshot =
      		innobase_start_trx_and_assign_read_view;
      

      I believe that XA START should invoke the above method. The benefit would be that if there is no other source of XA COMMIT statements than Spider, and if can guarantee the absence of the following kind of interleaved execution of XA START and XA COMMIT between shards, then Spider should be able get consistent non-locking reads across shards.

      A forbidden interleaving between XA COMMIT and XA START

      Let us assume that there are two client requests, COMMIT of a write transaction T1 and BEGIN of a read transaction T2 at roughly the same time.

      Internally, Spider implements COMMIT by executing XA PREPARE on each shard, and then executing XA COMMIT on each shard. It also should implement BEGIN by executing XA START on each shard.

      Let us say that we have shards A and B. The following interleavings are forbidden and must be prevented by some locking inside Spider. If that is the case and if XA START is fixed as proposed above, then we should get a consistent read view across the shards:

      A: XA COMMIT t1; XA START t2
      B: XA START t2; XA COMMIT t1

      That is, the XA COMMIT and XA START must be submitted to (and completed by) each shard in the same order.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                marko Marko Mäkelä
                Reporter:
                marko Marko Mäkelä
              • Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated: