Is it possible to ignore ConcurrencyExceptions in Axon?

Hi everybody!

Our business logic doesn’t have a problem if there is no strict order for the events that happen on an aggregate.
Therefore handling ConcurrencyExceptions using the axon RetryScheduler reduce our throughput without
bringing any advantage for our business case.

I know that I can use a DistributedCommand-Bus to avoid the ConcurrencyExceptions, but that would also restrict our throughput
to a single node.

So my question: Would it be possible in axon to allow concurrent modifications on the same aggregate?

So what I would like to have is:

  • Node X modifies Aggregate A in version 100 and fires an Event E1.
  • At the same time Node Y modifies Aggregate A in version 100 and fires an Event E2.
  • Aggregate A gets updated to Version 101 with Event E1 in the EventStore.
  • Afterwards aggregate A gets updated to Version 102 with Event E2.

If the business logic allows it, this would be the easiest way to get horizontal scaling.
So it would be nice if such a behaviour could be implemented using axon.

Thanks for any hints on achieving this with axon,
Dirk

Hi!

For test purposes, I simply removed the constrain on the DOMAIN_EVENT_ENTRY-Table which ensures, that

AGGREGATE_IDENTIFIER, SEQUENCE_NUMBER

is unique. By removing this constrain, I basically get what I described above:
There is no more exception when concurrent events on the same aggregate are fired.

Now, events on one aggregate can have the same Sequence Number if they have been issued in parallel.
What side effects do you expect from such a setup?
At least I would expect that I have to order now using the TIME_STAMP to get a reproducable aggregate from the store, right?

cu,
Dirk

The side-effect that this may have is that when sourcing from events, you apply state on a different (unexpected) state than at the time the event was generated. Whether this is an issue, really depends on your usecase.
Since you say that there is really no ordering, then you can simply remove the constraint. Events are ordered by the sequence number, so in certain cases you may have two events that come in in arbitrary order (since they have the same sequence number). That shouldn’t really be an issue.

So as far as I can tell, you can completely ignore TIME_STAMP.
Cheers,

Allard

Hi Allard!

Sounds good! Since I didn’t like to have two events with the same version number, I will try to extends the JDBCEventSourcingEngine to
use a sequence-table to create non conflicting versions. The only downside of this is that the version numbers of the events in conflict
will change after they have been written to the DOMAIN_EVENT_ENTRY Table.

Could Axon get a problem with changed version numbers on events?

cu,
Dirk

Hi,

Axon itself will not mind if sequence numbers of events change. These sequence numbers are only used to sort events in the correct order. However, when using Advanced Conflict Resolution, these sequence numbers are also used to detect potential conflicts. So combining advanced conflict resolution and changing sequence numbers is not recommended.

Cheers,

Allard