4 ms·

The author is arguing that we can always rewrite the txn logic such that (at least in the deterministic case) if one worker decides to commit, all others will d

The author is arguing that we can always rewrite the txn logic such that (at least in the deterministic case) if one worker decides to commit, all others will do so too. So a worker can proceed independently without other workers needing to finish their share of work and entering the commit protocol. The article doesn't go into exactly how this could work in the case of non-deterministic txns, but the linked papers may have an answer.

pacala 8y ago
Perhaps I'm not getting the setup right. Assuming that data is partitioned between worker A and worker B, I see no way to rewrite a distributed transaction to proceed based strictly on information available to A or to B. T( A.x = A.x - 1, B.y = B.y - 1, ) under constraints: A.x >= 0 B.y >= 0 What is the rewrite for the above transaction?
- abadid 8y ago
  On A: temp = remote read of y; if (temp >=1 && x >= 1) A.x = A.x - 1; 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.
  - j16sdiz 8y ago
    We can't do this on a modern NUMA computer. Good luck trying across different system.
  - lurker458 8y ago
    Is the cost of doing these remote reads worth the savings in this case ? After all to be correct, they need to run in the same transaction at the sending side and need to be persisted at the receiving side. Also, consider the effort if this gets scaled up to 10 cases (each node would have to do 9 remote reads)
    - abadid 8y ago
      They don't need to be persisted at the received side, but yes, there could be 9 remote reads if each of 10 shards are running code that may result in state-based aborts. Usually, however, only a subset of the shards run such code. But remember, 2PC requires 4 messages per worker (so 40 messages total in your example).
      - lurker458 8y ago
        True, but it's O(n^2) complexity instead of O(n) complexity (1000 shards would lead to 1M reads instead of 4k) 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)
        abadid 8y ago
        This requires a longer response that I have time write now. Please check back tomorrow night ...
        abadid 8y ago
        magicalhippo asked a similar question both with regard to complexity and garbage collection. I think it is best to combine these threads, so please see my response there ... https://news.ycombinator.com/item?id=19003212 https://news.ycombinator.com/item?id=19003212
      - oggy 8y ago
        I don't understand your point about only a subset of shards running code that may abort. Since we are talking about transactions, if there is even a single shard S that may abort (based on its state), then all other shards must also abort when S aborts. Which would imply that all other shards must also read the state of S before they commit. Am I missing something?
  - pacala 8y ago
    Interesting. This assumes there is a way to do consistent remote reads, that is some way to implement B.read(value=y, tx=T). Additionally, this works without using a global sync point, as per your other message. 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.
    - abadid 8y ago
      I understood and agree with all of your stated assumptions. However, I didn't follow your naive implementation. I would definitely caution against using a coordinator.
      - pacala 8y ago
        The transaction must enter the system somewhere. The 'coordinator' is that entry point, with a durable log so we don't inadvertently lose the transaction. It's only job is to push the transaction to all the workers involved.

pacala 8y ago

Perhaps I'm not getting the setup right. Assuming that data is partitioned between worker A and worker B, I see no way to rewrite a distributed transaction to proceed based strictly on information available to A or to B. T( A.x = A.x - 1, B.y = B.y - 1, ) under constraints: A.x >= 0 B.y >= 0 What is the rewrite for the above transaction?

abadid 8y ago
On A: temp = remote read of y; if (temp >=1 && x >= 1) A.x = A.x - 1; 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.
- j16sdiz 8y ago
  We can't do this on a modern NUMA computer. Good luck trying across different system.
- lurker458 8y ago
  Is the cost of doing these remote reads worth the savings in this case ? After all to be correct, they need to run in the same transaction at the sending side and need to be persisted at the receiving side. Also, consider the effort if this gets scaled up to 10 cases (each node would have to do 9 remote reads)
  - abadid 8y ago
    They don't need to be persisted at the received side, but yes, there could be 9 remote reads if each of 10 shards are running code that may result in state-based aborts. Usually, however, only a subset of the shards run such code. But remember, 2PC requires 4 messages per worker (so 40 messages total in your example).
    - lurker458 8y ago
      True, but it's O(n^2) complexity instead of O(n) complexity (1000 shards would lead to 1M reads instead of 4k) 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)
      - abadid 8y ago
        This requires a longer response that I have time write now. Please check back tomorrow night ...
        abadid 8y ago
        magicalhippo asked a similar question both with regard to complexity and garbage collection. I think it is best to combine these threads, so please see my response there ... https://news.ycombinator.com/item?id=19003212 https://news.ycombinator.com/item?id=19003212
    - oggy 8y ago
      I don't understand your point about only a subset of shards running code that may abort. Since we are talking about transactions, if there is even a single shard S that may abort (based on its state), then all other shards must also abort when S aborts. Which would imply that all other shards must also read the state of S before they commit. Am I missing something?
- pacala 8y ago
  Interesting. This assumes there is a way to do consistent remote reads, that is some way to implement B.read(value=y, tx=T). Additionally, this works without using a global sync point, as per your other message. 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.
  - abadid 8y ago
    I understood and agree with all of your stated assumptions. However, I didn't follow your naive implementation. I would definitely caution against using a coordinator.
    - pacala 8y ago
      The transaction must enter the system somewhere. The 'coordinator' is that entry point, with a durable log so we don't inadvertently lose the transaction. It's only job is to push the transaction to all the workers involved.