Jpa transaction manager transaction suspension ignores dialect resources [SPR-8771]

[spring-projects-issues]

Dejan Predovic opened SPR-8771 and commented

JpaTransactionManager.doSuspend() method fails to unbind the resource bound by the JpaDialect, so the pending transaction always fails with:

Caused by: java.lang.IllegalStateException: Already value [SessionImpl(PersistenceContext[entityKeys=[],collectionKeys=[]];ActionQueue[insertions=[] updates=[] deletions=[] collectionCreations=[] collectionRemovals=[] collectionUpdates=[]])] for key [org.hibernate.internal.SessionFactoryImpl@6921dcac] bound to thread [main]
at org.springframework.transaction.support.TransactionSynchronizationManager.bindResource(TransactionSynchronizationManager.java:180) ~[spring-tx-3.1.0.RC1.jar:3.1.0.RC1]
at org.springframework.orm.jpa.vendor.HibernateJpaDialect.prepareTransaction(HibernateJpaDialect.java:98) ~[spring-orm-3.1.0.RC1.jar:3.1.0.RC1]
at org.springframework.orm.jpa.vendor.HibernateJpaDialect.beginTransaction(HibernateJpaDialect.java:69) ~[spring-orm-3.1.0.RC1.jar:3.1.0.RC1]
at org.springframework.orm.jpa.JpaTransactionManager.doBegin(JpaTransactionManager.java:377) ~[spring-orm-3.1.0.RC1.jar:3.1.0.RC1]

It used to work in the last milestone.

---

Affects: 3.1 RC1

Issue Links:

• Transaction synchronization resources are not properly cleaned-up [SPR-8778] #13421 Transaction synchronization resources are not properly cleaned-up
• Regression: HibernateJpaDialect adding SessionFactory as txResource not getting cleaned up [SPR-8800] #13442 Regression: HibernateJpaDialect adding SessionFactory as txResource not getting cleaned up

Referenced from: commits f50f3d2

12 votes, 12 watchers

[spring-projects-issues]

Norbert Sándor commented

My problem may be related as well, please see: http://forum.springsource.org/showthread.php?116361-Spring-3.1.RC1-Hibernate-4.0.CR4-transaction-problem

[spring-projects-issues]

Mark Serrano commented

I have the same exception which occurs when I'm using Spring Batch and Spring 3.1.0.RC1.

I'm basically testing the sample football job in the Spring Batch samples and integrating it with the latest Spring 3.1.0.RC1 and Spring Data JPA project.

For reference, here's my exception:

 
org.springframework.transaction.CannotCreateTransactionException: Could not open JPA EntityManager for transaction; nested exception is java.lang.IllegalStateException: Already value [SessionImpl(PersistenceContext[entityKeys=[],collectionKeys=[]];ActionQueue[insertions=[] updates=[] deletions=[] collectionCreations=[] collectionRemovals=[] collectionUpdates=[]])] for key [org.hibernate.impl.SessionFactoryImpl@2ada52a1] bound to thread [main]
	at org.springframework.orm.jpa.JpaTransactionManager.doBegin(JpaTransactionManager.java:427)
	at org.springframework.transaction.support.AbstractPlatformTransactionManager.handleExistingTransaction(AbstractPlatformTransactionManager.java:423)
	at org.springframework.transaction.support.AbstractPlatformTransactionManager.getTransaction(AbstractPlatformTransactionManager.java:347)
	at org.springframework.transaction.interceptor.TransactionAspectSupport.createTransactionIfNecessary(TransactionAspectSupport.java:335)
	at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:105)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
	at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
	at $Proxy32.getLastJobExecution(Unknown Source)
	at org.springframework.batch.core.launch.support.SimpleJobLauncher.run(SimpleJobLauncher.java:94)
	at com.xtend.slb.repository.jpa.RecordRepositoryTest.testLaunchJob(RecordRepositoryTest.java:39)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
	at org.springframework.test.context.junit4.statements.RunBeforeTestMethodCallbacks.evaluate(RunBeforeTestMethodCallbacks.java:74)
	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
	at org.springframework.test.context.junit4.statements.RunAfterTestMethodCallbacks.evaluate(RunAfterTestMethodCallbacks.java:83)
	at org.springframework.test.context.junit4.statements.SpringRepeat.evaluate(SpringRepeat.java:72)
	at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:231)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
	at org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
	at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:71)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
	at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:174)
	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by: java.lang.IllegalStateException: Already value [SessionImpl(PersistenceContext[entityKeys=[],collectionKeys=[]];ActionQueue[insertions=[] updates=[] deletions=[] collectionCreations=[] collectionRemovals=[] collectionUpdates=[]])] for key [org.hibernate.impl.SessionFactoryImpl@2ada52a1] bound to thread [main]
	at org.springframework.transaction.support.TransactionSynchronizationManager.bindResource(TransactionSynchronizationManager.java:180)
	at org.springframework.orm.jpa.vendor.HibernateJpaDialect.prepareTransaction(HibernateJpaDialect.java:98)
	at org.springframework.orm.jpa.vendor.HibernateJpaDialect.beginTransaction(HibernateJpaDialect.java:69)
	at org.springframework.orm.jpa.JpaTransactionManager.doBegin(JpaTransactionManager.java:377)
	... 39 more

[spring-projects-issues]

Juergen Hoeller commented

We've taken a step back for 3.1 RC2 here: HibernateJpaDialect does NOT expose the underlying Session for the underlying SessionFactory anymore, so all of the suspension problems should be gone now. This was a bonus feature anyway - for which we unfortunately didn't think the consequences through.

Juergen