Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Regression: HibernateJpaDialect adding SessionFactory as txResource not getting cleaned up [SPR-8800] #13442

Closed
spring-projects-issues opened this issue Oct 24, 2011 · 3 comments
Assignees
Labels
in: data Issues in data modules (jdbc, orm, oxm, tx) type: bug A general bug
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Oct 24, 2011

Mike Youngstrom opened SPR-8800 and commented

Using Spring 3.1 rc1 I get a new error when using hibernate with JTA multiple times in the same thread. What appears to be happening is the HibernateJpaDialect is adding the Hibernate SessionFactory to the transactional resources for some reason. It assumes that when the transaction commits EntityManagerFactoryUtils.cleanupTransaction() will be called. However it doesn't in my situation.

I've included a maven test case. To duplicate simply run mvn test. If you change the version of spring to 3.0.6.RELEASE then the test passes.

Below is the exception I get:

java.lang.IllegalStateException: Already value [SessionImpl(PersistenceContext[entityKeys=[],collectionKeys=[]];ActionQueue[insertions=[] updates=[] deletions=[] collectionCreations=[] collectionRemovals=[] collectionUpdates=[]])] for key [org.hibernate.internal.SessionFactoryImpl@1d7b222] 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.EntityManagerFactoryUtils.prepareTransaction(EntityManagerFactoryUtils.java:230)
at org.springframework.orm.jpa.EntityManagerFactoryUtils.doGetTransactionalEntityManager(EntityManagerFactoryUtils.java:207)
at org.springframework.orm.jpa.SharedEntityManagerCreator$SharedEntityManagerInvocationHandler.invoke(SharedEntityManagerCreator.java:211)
at $Proxy16.getDelegate(Unknown Source)
at test.JpaTest$2.doInTransaction(JpaTest.java:32)
at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:130)
at test.JpaTest.test(JpaTest.java:30)
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.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
at org.testng.internal.MethodInvocationHelper$1.runTestMethod(MethodInvocationHelper.java:169)
at org.springframework.test.context.testng.AbstractTestNGSpringContextTests.run(AbstractTestNGSpringContextTests.java:158)
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.testng.internal.MethodInvocationHelper.invokeHookable(MethodInvocationHelper.java:181)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:684)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:883)
at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1208)
at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
at org.testng.TestRunner.privateRun(TestRunner.java:753)
at org.testng.TestRunner.run(TestRunner.java:613)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291)
at org.testng.SuiteRunner.run(SuiteRunner.java:240)
at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
at org.testng.TestNG.runSuitesSequentially(TestNG.java:1137)
at org.testng.TestNG.runSuitesLocally(TestNG.java:1062)
at org.testng.TestNG.run(TestNG.java:974)
at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:109)
at org.testng.remote.RemoteTestNG.initAndRun(RemoteTestNG.java:202)
at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:173)


Attachments:

Issue Links:

1 votes, 2 watchers

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Oct 30, 2011

Chris Beams commented

Thanks, Mike.

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Nov 15, 2011

Daniel Tabuenca commented

Definitely a problem for us. I am using the open session in view filter when using spring MVC to wrap a single transaction around everything which helps reduce the impact of this bug somewhat during MVC use.

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Nov 27, 2011

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: data Issues in data modules (jdbc, orm, oxm, tx) type: bug A general bug
Projects
None yet
Development

No branches or pull requests

2 participants