Duplicate revision id #72
Comments
|
Are you using eventstore only or in combination with cqrs-domain? |
|
This sort of features are handled by cqrs-domain. |
|
Interesting. Just using eventstore for now. So cqrs-domain is basically using another DB collection to keep track of locks on aggregates? What if the store just used a unique index on aggregateId/revisionId so it doesn't need a manual implementation in the command handler? |
|
this is just a fallback... to really solve the problem in a distributed system you have to ensure all commands of the same aggregate instance will target the same worker process... so you have to solve it on a system level. i.e. with rabbitmq and consistent hash exchange |
|
@adrai Don't want to hijack the topic but could you maybe explain consistent hash exchange a bit more? That seems quite relevant to issues I have been thinking about, i.e. two users issuing conflicting commands at ~ the same time to the same aggregate. If both get routed to the same worker then one of them will see an invalid state and can be rejected, effectively eliminating race conditions for a single aggregate in situations like this. |
|
https://github.com/rabbitmq/rabbitmq-consistent-hash-exchange Il giorno 11-set-2016, alle ore 23:47, Johannes Lumpe <[email protected]mailto:[email protected]> ha scritto: @adraihttps://github.com/adrai Don't want to hijack the topic but could you maybe explain consistent hash exchange a bit more? That seems quite relevant to issues I have been thinking about, i.e. two users issuing conflicting commands at ~ the same time to the same aggregate. If both get routed to the same worker then one of them will see an invalid state and can be rejected, effectively eliminating race conditions for a single aggregate in situations like this. You are receiving this because you were mentioned. |
I'm not sure if this is intentional feature or bug...
If I create two events for the same aggregateId at the same time using mongo store (haven't tried others), they are both commited successfully with the same revisionId. I would expect the store to throw for the second event so that it can retry (revalidate on the updated state and then commit if successful).
To illustrate this, given a bank account balance $5. If two commands come at the same time to withdraw $4 and withdraw $3, they will both validate against the perceived state ($5) and thus both will dispatch events, leading to the account being in negative balance.
Expected behavior would be for the first event to be commited to win, and the second to be forced to retry. In the above example, if the 4$ was withdrawn first, second command will be forced to retry against the new state ($1), not pass validation, and reject the command.
I imagine this could be worked around by using a synthetic eventId (e.g
aggregateId-expectedRevisionId), but I would think the store should handle this behavior, allowing any arbitrary eventId (eg uuid).Please correct me if my understanding is incorrect.
The text was updated successfully, but these errors were encountered: