Understanding Locks on Saga Tracking Token


We are currently struggling to understand how access to the Saga is handeld with the Axon tracking event processor.

A small Example:

We currently have multiple Microservices running all connecting to the same event/token/saga store(via jpa). These stores are all currently located in a Mysql DB(Precona XtraDB Cluster).

The metioned Services are all trying to write to the same Saga and this is where we seem to run into a problem.

As soon as one of the services writes the first value into the saga, he claims the tracking token and does not seem to let go afterwards anymore.

It seems like because of that we are currently running into problems accessing the saga from any other Service that is not currenly the owner of the Saga.

Is this expected behavior or is there some configuration we can do to prevent such a case?

Precision: Actually the events are handled in a quite proper way.

The surprise is araising from the EventHandler meant to resolve the subcription query being executed on another cluster node.
Thereby the QueryUpdateEmitter doesn’t reach the Flux waiting for feedback on the originating cluster node.

We are applying this template, which needs enhancement to become cluster enabled.


Hi Manuel, Jan,

I think you guys hit the issue that the QueryBus and QueryUpdateEmitter implementations which are currently in Axon Framework do not support a distributed mechanism, but only within one JVM.
If you need to dispatch queries and/or emitted query updates, you have three options:

  1. Create this yourself (might be a lot of work)
  2. Use Axon Server SE (free to use and the implementation can be read)
  3. Use Axon Server EE
    By the way, I am basing my response on Jan’s response stating the QueryBus.
    If this assumption was wrong, please correct me Manuel.