VoltDB/voltdb — pull request #1668 by eoneil1942 (2014-09-10 11:54:15+00:00)
Title: slowPath fix complete

Dear VoltDB developers--
As I previously discussed with John Hugg, I would like to contribute
a part of our CVoltDB project that is really just a performance bugfix
to VoltDB, specifically to slowPath. This fix was originally implemented
by Weiwei Gong in VoltDB 2.1.3, and I have ported it to version 4.7.
I have signed the contributor agreement. Of course if more of CVoltDB
project would be useful to you, I would be happy to help incorporate
those changes too. Also I could provide TPCB and the multi-partition TPCC.

I have forked the VoltDB repo using my github account eoneil1942,
made a branch called slowPathFix, and will put in a pull request.

This proposed change speeds up multi-partition transactions that contain
both read and write actions, such as TPCB (one read, 3 updates, 1 insert)
and TPCC payment. Also TPCC neworder made multipartition as originally
specified in the benchmark. These benchmarks are sped up by a factor
of 2 to 3 on 4 hosts.

The current implementation of slowPath splits up the original batch
into smaller batches each containing only read actions or only write
actions. Each batch execution requires a shot. TPCB's transaction
involves 5 shots. After this change, it is single-shot.

The reason for the small homogeneous batches is to ensure that the
reads and writes are done in proper order, while doing the replicated
reads at only one site. The new approach ensures the read/write
ordering by doing the original sequence of reads and writes on one site
(the buddy site). The other sites do all the actions in the original
order except the replicated reads. In the old way, the replicated reads
are done on the buddy site in the local work, where in the new way, they
are done on the buddy site in the distributed work, so the local work
only does accumulation of distributed results.

Here are the files and their edits:
ProcedureRunner.java: the top-level slowPath code
To avoid chopping the batch up into small batches, method
executeQueriesInIndividualBatches is gone, and the body of
executeSlowHomogeneousBatch becomes the body of the new version of slowPath,
retiring the now inappropriate method name.

Replicated read fragments are put into the distributed task in their
natural place, rather than in the local task. The array of boolean
"isReplicatedRead" records which fragments of the distributed task
are replicated reads, and this information is passed to
createAllParticipatingFragmentWork.

TransactionState.java, MpTransactionState.java:
Method createAllParticipatingFragmentWork accepts the new array argument
isReplicatedRead and prepares a second filtered version of the task
if there are any replicated reads in the batch. The filtered task
has no replicated reads. This filtered task is sent to non-buddy sites,
while the buddy site executes the full original task. After the
local work is done, the final results are assembled from the two
responses from the buddy site. If there are no replicated reads
in the task, the original task is sent to all sites.

VoltSystemProcedure.java: This code needs to call
createAllParticipatingFragmentWork with the isReplicatedRead array.
Since this code assumes a single fragment, it needs no special
read/write ordering treatment, and so the isReplicatedRead array
has a single false element.

TestMpTransactionState.java:
Method createTestPlan has code that parallels code in slowPath,
setting up batches, and thus needs similar changes to put the
replicated read fragments in the right task, etc. Also, it sets
up the appropriate isReplicatedRead array to go with the created remoteWork.

Method testOneSiteReplicatedReadFragment checks that there is a send
involved in createAllParticipatingFragmentWork (before there were no
such send). Removed the verify on the borrow task send since now
a pure replicated read batch has no borrow task.

Other tests: just added the plan's isReplicatedRead array to the call
to createAllParticipatingFragmentWork.

Let me know if I can help with the integration in any way.
Thanks, Betty (really Elizabeth) O'Neil
eoneil@cs.umb.edu
eoneil1942 at github