Event Sourcing Optimistic Concurrency-CodePudding

I'm trying to understand the idea of optimistic concurrency for Event Sourcing. Typically, optimistic concurrency is intended to be used for updates. However, in case of event sourcing, we never do updates - only insert.

Imagine we have 3 events to insert into the database. We check that current aggregate version is the same as expected and then do insert. But then it's possible that the aggregate is updated after the version check, but before the insert. To deal with it, we need to put version check and insert statement in transaction and therefore aquire exclusive lock.

So the question is, why is it still called optimistic concurrency, if we are using locks? Am I missing something?

CodePudding user response：

So the question is, why is it still called optimistic concurrency, if we are using locks? Am I missing something?

"Pessimistic" concurrency

LOCK
read
compute
write
UNLOCK

"Optimistic" concurrency

read
compute
COMPARE_AND_SWAP

The "optimism" that we are making a bet that no conflicting writes will appear while we are working. If we lose that bet, then COMPARE_AND_SWAP fails, and we have to start over (or give up). This essentially gives us "first writer wins" conflict resolution.

Note that an optimistic concurrency strategy constrains your storage design: you need to have an effective compare and swap operation available.

CodePudding user response：

In event sourcing the system is eventually consistent, so that if there are concurrent writes to the entity, once all nodes have received all the events for the entity they converge to the same state.

If you are storing your events in a database, you don't need to lock anything to store them. The event stream is WORM and append-only. Just add the events as they are recorded.

The mistake you're making is assuming "We check that current aggregate version is the same as expected and then do insert." The node that's writing the new event checks its own internal state, based on previously seen events, and if it can write an event it writes it. All nodes then read the event stream and converge to the correct state.