cockroachdb/cockroach — pull request #160 by spencerkimball (2014-11-07 02:10:05+00:00)
Title: Finish KV client Prepare/Flush; refactor client for simplicity.

This change brings full functionality to client Prepare/Flush
functionality, meaning parallel querying and updates are possible.
This requires unpacking a Batch request on the coordinator and
sending the constituent requests in parallel using goroutines.
I expect further improvements here, in particular, grouping commands
by range and sending those as batches all the way through, but
that'll require some more refactoring and remains down the road.

This change also removes the BeginTransaction command. Instead,
it's now handled seamlessly as part of the first call which goes
through the txn_sender. The advent of the prepare/flush concept
means that a transactional client no longer has to support multiple
goroutines which added a lot of complexity and required the
BeginTransaction command.

There's been a dramatic simplification of the client by doing two
things:

* Always return a fully updated transaction with the response
for calls which specify a transaction with the request. This
allows us to move the priority and timestamp updating to the
server. The client now only needs to update its transaction
with the one returned with each response.

* Move retries due to write intent and write-too-old errors to
the server. This eliminated the "single-call-sender" and also
the retry loop in the "txn-sender". Besides simplifying the
client, this also eliminates a round-trip when resolving an
intent on a write--I believe this is a significant
optimization for the common case.

We are able to move this retry logic into the server (in
storage/store.go) because I realized that we could simply
not write response to the response cache for these retryable
errors. Because there's nothing written, the server is
completely free to retry (and the client too!) without any
chance of the client seeing both error and success on
successive retries.

I also got rid of the increasingly-complex implementation of a
coordinator-like db_test in storage/. Instead, I moved the store
tests which require transactions (to do splits) into a new test
package, storage_test, so we can just use one implementation of
the coordinator (this is what keeps track of intents and cleans
them up).