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
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 ?
„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?