org.axonframework.repository.ConcurrencyException thrown when 2 events within the same Unit of Work for the same Aggregate are published

[mdm...@gmail.com]

Hi,

in our case, there are 2 publish calls for 2 different events (different class and seq. number) for the same aggregate one after another inside the same external command handler. We use a SQL event store. The cause of ConcurrencyException is then a JPA exception saying that the second event could not be persisted cause another event with the same identifier (meaning the unique column event identifier, probably) already exist in the DB table.

This is a seemingly similar problem to

https://groups.google.com/d/topic/axonframework/_By5Sm4MQMA/discussion

but it is different, because we publish the events inside the same thread, there is no code in between, actually. So, could this still be caused by the ACID transaction isolation level settings as Allard explained in the this thread ?

https://groups.google.com/d/topic/axonframework/4g6YX2czjpk/discussion

„The most common reason for this error is the database's (default) transaction isolation level. Some databases use repeatable read as default, which may cause this error. Using an isolation level of read committed will solve it.“

But: we are using SQL server and its default isolation level, which is already READ COMMITTED.

So what else could be causing this exception?

br

Marek

[Allard Buijze]

Hi Marek,

the exception (or one of the upstream causes) should identify the exact key that causes the conflict, including conflicting value. That should give you some hints of what's going on.

Cheers,

Allard

Op ma 16 okt. 2017 om 10:24 schreef <mdm...@gmail.com>:

--
You received this message because you are subscribed to the Google Groups "Axon Framework Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to axonframewor...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Allard Buijze

CTO

E: allard...@axoniq.io

T: +31 6 34 73 99 89

AxonIQ Conference - 29th September - in Amsterdam

[mdm...@gmail.com]

Yes, thanks, The root cause was the trivial fact, the event store table was missing the normally auto-generated primary key column. We had to create the table ourselves and missed that column.