T(
A.x = A.x - 1,
B.y = B.y - 1,
)
under constraints:
A.x >= 0
B.y >= 0
On B: temp = remote read of x; if (temp >=1 && y >= 1) B.y = B.y - 1;
I simplified the code a little by checking on the old value of x and y instead of the new one, but I could have written the code to check on the new value instead.
But remember, 2PC requires 4 messages per worker (so 40 messages total in your example).
If they're not persisted at the receiving side, how does it handle a crash before committing on the receiving node ? Keeping previous versions indefinitely on sending nodes to permit requesting the old values doesn't work, so this introduces a time bound on how long a crashed node has to recover (granted, this could still mean weeks)
Naive implementation:
* B just blocks the read call until T is ready for execution, then returns the value of y.
* The coordinator C pushes the transactions to both A and B until they independently ACK, so B never blocks forever.
* Assuming serializable A and B.
Would be interesting to see how this performs compared with vanilla 2PC. The one downside I see is that if B vanishes for a prolonged amount of time, A is stuck waiting on its read call without a mechanism to drop the distributed transaction T and go on with its other duties.