12 Apr 2014, 21:36

Craig Barrett (1 post)

After reading the section on alter vs commute and the STM, I was less than enlightened. Perhaps I’ve just missed something, but I don’t see how the use of alter can guarantee that the order in which the ref is updated will be as expected when the order of the transactions is not guaranteed and a transaction involving alter can restart if some other transaction completed first. What alter does guarantee is that the value returned will be the result of applying the function to the in-transaction value retrieved at the start of the transaction, whereas commute makes no such promise. But that in-transaction value to which alter applies the function may not actually be the value of the ref at the time the transaction originally started. I.e., in the chat application example, if message 1 is received and a transaction to add the message to the list starts, but before it completes message 2 is received and another transaction starts, which then completes first, the list will have the messages ordered with message 2 appearing to have been received earlier.

Unfortunately, searching around online hasn’t helped because the best that is offered is pretty much the same as what’s in this book. Lots of examples, showing multiple commutes returning the same value, but ultimately the value after all are committed being what was expected, whereas alter restarts transactions and so all the alters return unique values (unless, of course, separate alterations an result in the same value). But that’s kind of like pointing to someone riding a bike as an explanation of the role the wheels play in keeping the bike upright.

Perhaps a complete explanation of how it is that alter guarantees the ordering? Because right now I find myself in a position where I see the decision of whether to use commute or alter as being predicated on something like a bank balance scenario -
1. balance is x
2. a withdrawal is requested, so start the transaction. x - amount >= 0 and the transaction knows it can proceed.
3. a payment is requested, so start the transaction. x - bill >= 0, so the transaction knows it can proceed.
4. payment completes and balance is now y. But y - amount < 0, so the withdrawal should not be allowed to proceed.

If commute is used, the result will be a negative balance. If alter is used, the first transaction would restart, discover the balance would be negative and an exception would presumably be thrown. That’s all well and good and fits the bit where the book (and others) state that the transaction restarts if alter is used. However, it doesn’t fit the bit where the book claims that use of alter ensures that the withdrawal happens first (which would result in the payment failing instead), the equivalent of ensuring that the chat messages appear in the correct order.

  You must be logged in to comment