← Graph

How do you prevent race conditions?

question 2 connections

Audience member asks whether events and read models are stored in the same transaction or how race conditions are handled with multiple workers. Ismael acknowledges event sourcing is conceptually simple but operationally complex: many workers competing for the same commands, partitioning for ordering, exactly-once handling, locking and transactions all have to be solved. Sourced uses a claim mechanism similar to Solid Queue — a row/flag in the database that a worker acquires before handling events/commands/projections for a partition, releasing it when done so other workers can take over. He offers to show the code but warns it is quite complex.

answer_summary
Sourced takes a Solid-Queue-style claim/lock per partition so only one worker processes events for that partition at a time; it's released when done.
question How do you prevent race conditions?
about
Sourced project
Specifically about Sourced's concurrency handling (claim mechanism).
question How do you prevent race conditions?
asked_at
Q&A about concurrency.

Provenance