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.