> There can't be consistency without communication.

True

> The trick is to minimize the communication

True

> and, to the degree possible, allow it to operate asynchronously.

True again.

> A pending transaction can make a tentative
> update and continue to execute pending a return message from the
> resolution agent as long as it can rollback to the update statement and
> return an error like a proper SQL database. This means, specifically,
> that a mass update can have hundreds of pending resolution in flow, so
> it needn't block until statement end and it has to return a proper
> status code to the client.

Why does this approach minimize communication? Is it not much more
efficient to order writes and reject attempted commits whose write set
overlaps with an earlier, concurrent commit?

Paul