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
@EventSourcingHandler
annotated method - Adding an annotated
@SequenceNumber
parameter to each@EventSourcingHandler
method
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
@AggregateVersion
field at all when the aggregate instance can simpy get it from theAggregateLifecycle
? - Is there an easier, more reliable way of setting it, as opposed to having to do it manually in
@EventSourcingHandler
methods? - Exactly how and when does the framework use the annotated field, if at all?
Thanks in advance, Andy.