Command Handler Synchronization

Hi,

i am a constant reader of this excellent group but did not yet find a sufficient answer for my question here or in the Axon Docs:

For a Use-Case we are currently implementing, we need to make sure that after handling a specific Command the state of the affected Aggregate-Instance is up to date before the next Command of the same kind is handled. A brief description of our use-case: we’re maintaining jobs that can be assigned to a processing node. Through command validation we want to make sure that a job can only be assigned to a processing node once:

`

@Aggregate(type = “Job”)
public class JobAggregate extends AbstractOrganizationAggregate {

//
/
internal aggregate state /
/
/
@AggregateIdentifier
protected String guid;
private String processingNodeId;

/**

  • Handles a {@link JobAssignCommand}.

Hi Jakob,

You can regard “the state of the affected Aggregate-Instance” to be up to date as soon as you’ve received the return value of dispatching said command.
Axon underneath uses the notion of a Unit Of Work to stage operations like storing a published event, after all execution has been resolved.

Added to this, in case concurrent commands are send towards a given Aggregate Instance, you will automatically be guarded from concurrent execution due to the aggregate locking factory in place as part of any out-of-the-box Repository implementation you select.
Thus, within a single JVM, you will be ensured concurrent command handling cannot occur for a single Aggregate instances.

When you start distributed your application, the locking solution does not distribute with you.
Instead, we suggest you use a distributed command bus solution, like Axon Server, to ensure consistent routing of a command.
Doing so ensure that the same application will always handle commands for a given Aggregate instance.

If this due to some off scenario concurrent execution of a given Aggregate instance still happens, then the Event Store will kick in with the unique constraint of Aggregate Identifier and Sequence Number.

Axon will throw a ConcurrencyException if the application tries to insert an event who’s aggregateId-seqNo pair already exists.

Hope this explanation alleviates any concerns you might have Jakob!

Cheers,
Steven

Hi Steven,

thanks for your detailed answere. That clarifies my questions and confirms the behaviour we assumed it would have.

Regarding your suggestions:

When you start distributed your application, the locking solution does not distribute with you.
Instead, we suggest you use a distributed command bus solution, like Axon Server, to ensure consistent routing of a command.
Doing so ensure that the same application will always handle commands for a given Aggregate instance.

We’re actually using Axon Server to distribute our application, so we should be safe on that as well, as the same aggregate instance is ensured to be handled on the same application instance by Axon Server.

Best Regards,
Jakob

Hi Jakob,

Great to hear this helped you out.
Sounds like you’re all set for a distributed Axon application as well, I am happy to hear that. :slight_smile:
If any further questions arise, you know where to contact us!

Cheers,

Steven van Beelen

Axon Framework Lead Developer

AxonIQ
Axon in Action Award 2019 - Nominate your project