Replies: 2 comments
-
To give more information on the solution that we use. It is described here: https://jasperfx.github.io/marten/documentation/scenarios/aggregates_events_repositories/ |
Beta Was this translation helpful? Give feedback.
0 replies
-
@oskardudycz I think I'd rather try to handle this with optimistic concurrency similar to how we do the documents. Give you the chance to mark a certain stream type or event collection as versioned with the same kind of workflow. I know we have some version checking now, but there are open issues for that. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
We have a setup where we process messages from a message queue. For each message we load our aggregate to see if we need to update it or we are in the correct state. Afterwards we manually generate some readmodels from the updated aggregate.
We have just found that if we have two consumers that process messages for the same aggregate id, both of them get to write their events to the event stream due to the fact we are not checking that the aggregate has not been updated since it was loaded.
I have found a way to handle this, and that is by manually updating a version number on my aggregate every time apply is called. I just find that this is a bit crued.
I thought that there might be a better way to handle this.
The idea I had was to create something like the Id assignment, but for version instead. That way you can create a property on your aggregate, to hold the current version number. It should be optional if you wanted to have this property on your aggregate.
Beta Was this translation helpful? Give feedback.
All reactions