OK, maybe not an entirely stupid question given I’ve only been looking at Axon < 1 week. But then again…
At the moment I’m trying to get my head around how optimistic locking / conflict resolution would work in practical terms but the documentation is a little lacking in this regard, so…
I’m hoping someone can explain the practical usage of the
@AggregateVersion annotation. I’ve been doing some experimenting and can see that the
AggregateLifecycle keeps track of the version based on applied events. I have access to this from anywhere inside the
Aggregate instance and can easily look it up when required, so from an aggregate lifecycle perspective the adoption of an annotated field feels somewhat redundant.
My next thought was in regards to how the field was actually being set, I had naively assumed the framework would set the
@AggregateVersion field value as part of the event publishing mechainsm, or, once an aggregate had been fully hydrated (after initializing), but this is not the case and it seems I would be responsible for setting this field. As far as I can tell this would involve:-
- Incrementing the field on each invocation of an
- Adding an annotated
@SequenceNumberparameter to each
This means having to add the same line of code to each handler method to update the aggregates version field. Neither method is ideal and both error prone, e.g. developers forgetting to code for it.
So, to the point of the post:-
- In terms of using a version for optimistic locking, why bother with an
@AggregateVersionfield at all when the aggregate instance can simpy get it from the
- Is there an easier, more reliable way of setting it, as opposed to having to do it manually in
- Exactly how and when does the framework use the annotated field, if at all?
Thanks in advance, Andy.