TrackingEventProcessor race conditions?

Hey there,

We have hit an issue with using TrackingEventProcessors and we cannot seem to figure out a way around it. Currently, We have commands going against two event sourced aggregates being managed by a saga with output to a single query model. We want to use a tracking processor to get the benefits of having the events running asynchronously off the commands. We get the following exceptions when running our application with TrackingEventProcessor:

10:31:25,214 WARN [org.axonframework.eventhandling.TrackingEventProcessor] (TrackingEventProcessorá-…pim.axon.prototype2.queryside.model-0) Error occurred. Starting retry mode.: java.lang.NullPointerException
at org.hibernate.engine.jdbc.connections.internal.DatasourceConnectionProviderImpl.closeConnection(
at org.hibernate.internal.AbstractSessionImpl$NonContextualJdbcConnectionAccess.releaseConnection(
at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.releaseConnection(
at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.afterStatement(
at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.afterStatementExecution(
at org.hibernate.hql.internal.ast.exec.BasicExecutor.doExecute(
at org.hibernate.hql.internal.ast.exec.BasicExecutor.execute(
at org.hibernate.hql.internal.ast.QueryTranslatorImpl.executeUpdate(
at org.hibernate.engine.query.spi.HQLQueryPlan.performExecuteUpdate(
at org.hibernate.internal.SessionImpl.executeUpdate(
at org.hibernate.internal.QueryImpl.executeUpdate(
at org.hibernate.jpa.internal.QueryImpl.internalExecuteUpdate(
at org.hibernate.jpa.spi.AbstractQueryImpl.executeUpdate(
at org.axonframework.eventhandling.tokenstore.jpa.JpaTokenStore.extendClaim(
at org.axonframework.eventhandling.TrackingEventProcessor.lambda$processBatch$5(


Hey there,

Is there any information we can add to this question. We are pretty stuck here and am not sure of next steps.


Hi Justin,

I noticed you're using the SimpleEntityManagerProvider. This one assumes
that the EntityManager you use is reusable over requests. I'm not sure if
that's the case here. You might need to return a new instance for each
transaction, but I'm not sure.

I also see some references to Spring, but you don't seem to be using Spring
to configure the Axon components. Is there a specific reason for it?

Lastly, the tracking processors don't use the transaction of the Command
Bus, since they run their own threads to process events. They need their
own transaction manager. By configuring the transaction manager in the
Configuration (which you've done), the tracking processors should
automatically use that transaction manager.

From your stacktrace, it seems that the transaction isn't running on the

entity manager anymore (thus refusing the update). My first remark might
have something to do with that.

Hope this helps.


Thanks Allard,

I will be applying these thoughts today. As well, we started with a proof of concept outside of spring that just includes the default configurer. I think we are close to the point now where we can where we can fully spring load this via axons auto-configuration. We just need a working prototype before getting to that step.

Ill post the outcome.



We were able to get it to work with the ContainedManagedEntityManagerProvider. The entity management life cycle was affecting everything outside of in memory stores.

Thanks again Allard. Its looking like we are close.