alt Hacker NewsIf the read and the write are separate messages, i.e. the computation of the modified value happens sender-side, as in the parent example, then I don’t see how a serializing queue prevents the race condition, for two concurrent senders (clients). For that you need transactions, exactly like a database.
Replies
mrkeen • yesterday at 8:47 PM
This is correct, but databases only help to the extent that the whole world is happy to live in your database.
As soon as you have customers (who interact via REST), or partner payment systems (e.g. stripe) you're back to:
Two customers do a GET. This gets dispatched to the DB, wrapped in a nice transaction, the transaction ends, the customers get their result.
The two customers then do a POST to set a new value. Also wrapped in a transaction.
➕ show 1 reply
That's not how you would implement mutating messages in an actor system. Instead you could do either of these:
* Have an "increment" message that adds n to the current value and returns the old value.
* Have separate "read" and "write" messages, where the "write" message is parameterized by a timestamp returned by the "read" message. If the owner detects that the timestamp sent by the write is older than the most recent timestamp, it's rejected.
Because messages are handled serially, it's easy and safe to create messages that behave sanely event without explicit locks.