Caused by: javax.persistence.TransactionRequiredException: no transaction is in progress

Hi, any idea why I get this nasty error with transactions when using entityManager to persist/ merge in an asynchronous request handling scenario (@EnableAsync).

Caused by: javax.persistence.TransactionRequiredException: no transaction is in progress
	at org.hibernate.internal.SessionImpl.checkTransactionNeeded(SessionImpl.java:3430)
	at org.hibernate.internal.SessionImpl.doFlush(SessionImpl.java:1397)
	at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1393)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.springframework.orm.jpa.ExtendedEntityManagerCreator$ExtendedEntityManagerInvocationHandler.invoke(ExtendedEntityManagerCreator.java:347)
	at com.sun.proxy.$Proxy130.flush(Unknown Source)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.springframework.orm.jpa.SharedEntityManagerCreator$SharedEntityManagerInvocationHandler.invoke(SharedEntityManagerCreator.java:298)
	at com.sun.proxy.$Proxy129.flush(Unknown Source)
	at org.springframework.data.jpa.repository.support.SimpleJpaRepository.flush(SimpleJpaRepository.java:555)
	at org.springframework.data.jpa.repository.support.SimpleJpaRepository.saveAndFlush(SimpleJpaRepository.java:523)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.springframework.data.repository.core.support.RepositoryFactorySupport$QueryExecutorMethodInterceptor.executeMethodOn(RepositoryFactorySupport.java:504)
	at org.springframework.data.repository.core.support.RepositoryFactorySupport$QueryExecutorMethodInterceptor.doInvoke(RepositoryFactorySupport.java:489)
	at org.springframework.data.repository.core.support.RepositoryFactorySupport$QueryExecutorMethodInterceptor.invoke(RepositoryFactorySupport.java:461)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
	at org.springframework.data.projection.DefaultMethodInvokingMethodInterceptor.invoke(DefaultMethodInvokingMethodInterceptor.java:56)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
	at org.springframework.transaction.interceptor.TransactionInterceptor$1.proceedWithInvocation(TransactionInterceptor.java:99)
	at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:282)
	at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
	at org.springframework.dao.support.PersistenceExceptionTranslationInterceptor.invoke(PersistenceExceptionTranslationInterceptor.java:136)
	... 27 common frames omitted

I have similar issue posted on stackoverflow couple of days ago, but none of suggested solutions work: https://stackoverflow.com/questions/49548010/exception-in-spring-asynchronous-job-invaliddataaccessapiusageexception-no-tr?answertab=votes

Thanks,
Shravan

I see that the stacktrace contains the TransactionInterceptor which is responsible for starting a new transaction.

This is either a Spring configuration issue or some bug. Try to debug it and see why the JPA transaction is not set. Also, the Spring developers can better help you with this problem as this is not a Hibernate issue.

Thanks for your response Vlad. I have tried using the DebugUtils mentioned here - blog.timmattison.com/archives/2012/04/19/… and I have noticed from log, there is an active transaction before I call flush… but still this does not work. Do you still think this could be something I need to ask at spring forums?

It’s good to try yes. But, you can also debug the Spring code base and figure out why it does not see the transaction context set by the TransactionInterceptor. It’s just source code like any other Java code, after all.

Having a similar issue when attempting flush session . We are migrating to Hibernate 5.3.4. Previous version was Hibernate 3.2…

Can some one redirect me to the appropriate thread in spring forums?
Thanks

If you upgrade Hibernate, most likely that you need to upgrade Spring as well and use the org.springframework.orm.hibernate5.HibernateTransactionManager.

Thanks for the answer Vlad,

We are also migrating from Spring 2.3 to Spring 4.3.

We are using Websphere transaction Manager, with spring declarative transaction management. Since we use multiple transnational resources:

[org.springframework.transaction.jta.WebSphereUowTransactionManager]

The Tx works for read and write operations, but we get a TransactionRequiredException when we explicitly call flush method from hibernate session.

Note we are not using hibernate.current_session_context_class parameter since we understand this conflicts with spring SessionContext set the Spring Declarative Tx Management.

Any ideas what could be the cause? Do you suggest to accommodate HibernateTransactionManager instead?

The HibernateTransactionManager is for RESOURCE_LOCAL transactions. In your case, it’s ok to use the JTA one. But why use Spring and WebSphere?

Hello
Our application is deployed in WebSphere Application server (8.5.5.13) . We wanted to use the related spring Tx manager to leverage the support from the application server transaction coordinator.

I find it unusual to run a Spring application inside a JavaEE application server. If you only needed the JTA TM, you could use Bitronix or Atomikos.

Yes, its unusual, but before migration it was reliable : For our solution, Spring provided better approaches than JEE alone . It was not only the JTA TM. Cant go back on that design decision.

May I post more information about the context of the exception ? spring context configurations ?

I’m sure the Spring team knows better about this Exception. From a Hibernate perspective, this is an integration issue.

Ok, thanks Vlad, will post the exception for Spring team.

Hi, I am facing the same issue, can you tell me what fix was worked for ?