ConcurrencyException when repeatable read transaction isolation level is set

Imported from Google Groups
1

Hi

Sometimes I get ConcurrencyException when multiple threads try to update the same aggregate. I use MySQL with ‘repeatable read’ isolation level.
I know that changing to ‘read committed’ isolation level will help but I cannot do that.

What else can I do to fix this problem?

Cheers

Filip

2

Hi Filip,

another thing that may help prevent this issue is to delay creation of a transaction to the latest moment possible. Spring provides a (sorry, don’t recall the actual name, and can’t look it up at the moment) LazyConnectionDataSource[Proxy/Wrapper/…]. It waits with opening a connection until it’s actually being used to perform a query.

Alternatively, or in addition, you can use the RetryScheduler on the CommandGateway. Commands that result in this exception can be safely retried.

Hope this helps.
Cheers,

Allard

3

Thanks for ideas.

I have changed transaction isolation level to ‘read committed’. I didn’t know that I can do that on a connection level.

Now it works but only when a single instance is used. I still have a problem because two instances consume external events from rabbitMq and try to change the same aggregate at the same time.

Why ‘read committed’ helps only when a single instance is used? Isn’t a common problem? I think that RetryScheduler could help but sometimes it won’t prevent failure.

Regards,
Filip

4

Hi Filip,

From your description I get the idea you’ve got two identical Axon application, both listening to a queue and based on that you publish commands.

Through that approach it’s somewhat harder to coordinate which node will handle which aggregate.
Are the actions you try to take on the aggregate identical or two different actions?

The DistributedCommandBus is able to correctly coordinate which node will be in charge of firing a command for a given Aggregate.
It does that internally by using the RoutingStrategy interface, which is a decision point for which node will handle which aggregate.
Doing this is also beneficial from that point that not more then one node would have to event source, and potentially cache, an aggregate.
So I’d suggest configuring a DistributedCommandBus in your application to deal with deciding which instance is gonna handle which aggregate.

Hope this helps Filip!

Cheers,
Steven