search

ylorph / The-Inevitable-Event-Centric-Book

Some day, someone might write an authoritative book about this aspect. Let's call that inevitable book Event Centric as a placeholder title (this is a quote...)
71 stars 7 forks source link

Problem: Handling Concurrency #56

Open ylorph opened 3 years ago

ylorph commented 3 years ago
MerrionComputing commented 3 years ago

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

ylorph commented 3 years ago

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 commented 2 years ago

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

mattbishop commented 1 year ago

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.