-
Notifications
You must be signed in to change notification settings - Fork 5
Optimistic Locking
Jose San Leandro edited this page Apr 8, 2021
·
1 revision
- If events (belonging to a single aggregate) generated from a single command share the same version, MongoDB unique index must use the
id, the version and the event type.idandversionalone won't work. - [TODO] Find out if MongoDB's unique indexes work in replica sets.
- Think (and try) of using the aggregate as part of the routing key. Find out if we can use "anything but" as routing key.
- Try out EventStore and find out how it solves the locking problem.
- We shouldn't force other systems to synchronize version of our aggregates. Otherwise they won't be able to choose what events to consume, and we'll end up polluting every microservice with information they don't need, only because we need them to.
- If we use declarative commands, would it simplify optimistic locking?
- We could use an "append-only" collection, with information about the latest version of each aggregate, instead of polluting the version information to other services. PharoEDA, when reconstructing the aggregate, takes the version out of the new collection. When saving the events, we know the old and the new versions. In MongoDB we need to find out how to perform a "select for update"-like operation that allows us to insert the new events if the old version of the aggregate match the current value of the new collection, or reject it otherwise.