Problem: Handling Concurrency

[ylorph]

• @MerrionComputing concurrency 🐊
• pessimistic:
  • checkout / checkin
• optimistic locks
• no concurrency
• stream design
• merge
• deduplicate
• Actor Model

[MerrionComputing]

Does the actor model handle concurrency or more prevent it (by being effectively synchronous single threaded inside the actor)?

[ylorph]

well it a way to prevent concurrent append to a stream , as well as keeping it's projectected state in memory.
( if only 1 actor has ownership of appending to a stream )

[MerrionComputing]

Added some thoughts in this article: https://github.com/MerrionComputing/Presentations/blob/master/Articles/taming-the-concurrency-crocodile.md

[mattbishop]

I've been working on this problem in Evently, and came up with a solution I'm calling Atomic Append. Basically one creates a selector to look for events across all streams in the ledger, and then if the read model from that stream is satisfactory, Evently will use that same selector to atomically append the new event. If the selector has new events in the interim, it rejects the append and the client can try again with another hydration or communicate the failure. This is similar to Solution 3 in @MerrionComputing's article, but simpler.

The example I use in Evently is Account Registration where one can only register unique usernames. First a command looks for account registration events where the username in the event matches the command's username. If no events are found, the append request is sent using the selector ID. Evently checks the selector and appends the event if the attached selector selects no new events. This atomicity mirrors the SQL Atomicity and its INSERT / UPDATE ... WHERE statements.