Aggregate does not continue with the sequence number in the database but attempts to start with 0

Dear all,

I’m developing an application, which keeps dealers in PostgreSQL. My axon aggregate class uses an identifier, which is composed of dealers dispatch type and account number, which is a unique identifier defined by the business logic.

My app supports file import of dealers with the following logic:

  • New dealers are inserted into db (CreateDealerCommand)
  • Existing dealers are updated (UpdateDealerCommand)
  • Dealers missing in the file are removed from the database (DeleteDealerCommand)

Unfortunately, I have an issue with the scenario, where the dealer is firstly created using CreateDealerCommand, then removed using DeleteDealerCommand and lastly created again using CreateDealerCommand.
The first two commands (CreateDealerCommand and DeleteDealerCommand) are successfully executed and two events are stored in db, both with identifier 03013712 and increasing sequence (0 and 1).Výstřižek.PNG

However, when I try to create the dealer with identifier 03013712 again, I’m not able to continue in the sequence and the app starts a new sequence.


org.axonframework.modelling.command.ConcurrencyException: An event for aggregate [03013712] at sequence [0] was already inserted
at org.axonframework.eventsourcing.eventstore.AbstractEventStorageEngine.handlePersistenceException(
at org.axonframework.eventsourcing.eventstore.jpa.JpaEventStorageEngine.lambda$appendEvents$6(
at org.axonframework.common.transaction.TransactionManager.executeInTransaction(
at org.axonframework.eventsourcing.eventstore.jpa.JpaEventStorageEngine.appendEvents(
at org.axonframework.eventsourcing.eventstore.AbstractEventStorageEngine.appendEvents(
at org.axonframework.eventsourcing.eventstore.AbstractEventStore.prepareCommit(
at org.axonframework.eventhandling.AbstractEventBus.doWithEvents(
at org.axonframework.eventhandling.AbstractEventBus.lambda$null$8(
at org.axonframework.messaging.unitofwork.MessageProcessingContext.notifyHandlers(
at org.axonframework.messaging.unitofwork.DefaultUnitOfWork.notifyHandlers(
at org.axonframework.messaging.unitofwork.AbstractUnitOfWork.changePhase(
at org.axonframework.messaging.unitofwork.AbstractUnitOfWork.commitAsRoot(
at org.axonframework.messaging.unitofwork.AbstractUnitOfWork.commit(
at org.axonframework.messaging.unitofwork.DefaultUnitOfWork.executeWithResult(
at org.axonframework.commandhandling.SimpleCommandBus.handle(
at org.axonframework.commandhandling.AsynchronousCommandBus.lambda$handle$0(
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(
at java.base/java.util.concurrent.ThreadPoolExecutor$
at java.base/
Caused by: javax.persistence.PersistenceException: org.hibernate.exception.ConstraintViolationException: could not execute statement
at org.hibernate.internal.ExceptionConverterImpl.convert(
at org.hibernate.internal.ExceptionConverterImpl.convert(
at org.hibernate.internal.ExceptionConverterImpl.convert(
at org.hibernate.internal.SessionImpl.doFlush(
at org.hibernate.internal.SessionImpl.flush(
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(
at java.base/java.lang.reflect.Method.invoke(
at org.springframework.orm.jpa.SharedEntityManagerCreator$SharedEntityManagerInvocationHandler.invoke(
at com.sun.proxy.$Proxy158.flush(Unknown Source)
at org.axonframework.eventsourcing.eventstore.jpa.JpaEventStorageEngine.lambda$appendEvents$6(
… 17 common frames omitted
Caused by: org.hibernate.exception.ConstraintViolationException: could not execute statement
at org.hibernate.exception.internal.SQLStateConversionDelegate.convert(
at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(
at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(
at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(
at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(
at org.hibernate.persister.entity.AbstractEntityPersister.insert(
at org.hibernate.persister.entity.AbstractEntityPersister.insert(
at org.hibernate.action.internal.EntityInsertAction.execute(
at org.hibernate.engine.spi.ActionQueue.executeActions(
at org.hibernate.engine.spi.ActionQueue.executeActions(
at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(
at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(
at org.hibernate.internal.SessionImpl.doFlush(
… 25 common frames omitted
Caused by: org.postgresql.util.PSQLException: ERROR: duplicate key value violates unique constraint “domain_event_entry_uq_aggregate_sequence”
Detail: Key (aggregate_identifier, sequence_number)=(03013712, 0) already exists.
at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(
at org.postgresql.core.v3.QueryExecutorImpl.processResults(
at org.postgresql.core.v3.QueryExecutorImpl.execute(
at org.postgresql.jdbc.PgStatement.executeInternal(
at org.postgresql.jdbc.PgStatement.execute(
at org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(
at org.postgresql.jdbc.PgPreparedStatement.executeUpdate(
at com.zaxxer.hikari.pool.ProxyPreparedStatement.executeUpdate(
at com.zaxxer.hikari.pool.HikariProxyPreparedStatement.executeUpdate(
at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(
… 33 common frames omitted


I have the following aggregate to handle my commands

public class DealerAggregate {

    //dispatch type + account number
    private String composedCode;

    public DealerAggregate(CreateDealerCommand cmd) {
        apply(new DealerCreatedEvent(cmd.getMetadata(), cmd.getDealer()));

    public void on(UpdateDealerCommand cmd){
        apply(new DealerUpdatedEvent(cmd.getMetadata(), cmd.getDealer()));

    public void on(DeleteDealerCommand cmd){
        apply(new DealerDeletedEvent(cmd.getMetadata(), cmd.getDealer()));

    public void on(DealerCreatedEvent event) {
        composedCode = event.getDealer().getDispatchTypeCode() + event.getDealer().getAccountNumber();

I tried to create a method like below, however, it’s never called.


    public void on(CreateDealerCommand cmd){
        apply(new DealerCreatedEvent(cmd.getMetadata(), cmd.getDealer()));


Do you please have any ideas on how to deal with this issue? I tried to create a new void method on(CreateDealerCommand) however, this method is never called.

Thank you in advance!
Best regards,
Jaroslav Schnaubert

Forgot to mention - I use axon version 4.1.1

Dne čtvrtek 5. března 2020 15:48:49 UTC+1 Jaroslav Schnaubert napsal(a):

The first event from the created command is treated special. It should always be the first event and can happen only once.
I think you have to check in the CreateDealerCommand if the dealer already exists (technically) and then apply a special event ( ‘DealerRecreated’ ? ) instead of the DealerCreatedEvent.

Ow, i think you even have to create a specialised command for it , because it can not be a constructor command again, so you have to do the check in the client.

Axon 4.3 has a creationPolicy Annotation. Maybe you can do something with that :


Can we use this feature with the axon server 4.2.4? Means can we upgrade to axon framework 4.3 with any axon 4.x version?

Best, Michael

Hi Michael,

You can use creationPolicy feature with this version of the Axon Server as well.

Hi all,

Jaroslav, you are expecting to be able to reuse the aggregate identifier 03013712 because you did a “domain specific” delete of the aggregate.
However, as you are doing event sourcing, this is only a conceptual delete, but the fact it existed still remains.
Hence, the uniqueness constraint kicks in as soon as you try to create an aggregate with the same identifier.

We typically suggest to use a UUID as the aggregate identifier.
You are obviously free to use other formats than a UUID, but know that once used, you cannot delete the fact.

Hope this sheds some light on the situation.


Steven van Beelen

Axon Framework Lead Developer



Dear Gerlo, thanks, the creationPolicy works perfectly for my case!

Dne neděle 8. března 2020 13:43:22 UTC+1 Gerlo Hesselink napsal(a):