This is now fixed on GitHub master. Thanks again for reporting! Lukas
2014-10-29 15:50 GMT+01:00 Lukas Eder <[email protected]>: > Hello, > > Thanks for reporting this. You're right, there should be some additional > defensiveness around that rollback call - probably logging to the error > logger and then proceeding with throwing the cause. I've registered an > issue for this, which will be fixed in jOOQ 3.5.0 and 3.4.5: > https://github.com/jOOQ/jOOQ/issues/3718 > > Unfortunately, I don't know why your connection is already closed. Do you > have a small project setup that helps reproducing this issue? > > Cheers, > Lukas > > 2014-10-27 23:27 GMT+01:00 Eelco Hillenius <[email protected]>: > >> Hi, >> >> I love that jOOQ has integrated transaction handling now. One of the >> rough spots I found however is that when an exception happens during a >> transaction and the rollback that jOOQ then tries to perform fails, it'll >> 'eat' the exception that caused it. I'm not sure why the rollback fails in >> the first place, probably something specific to my environment (using >> MySQL, a custom Guice setup - though using the Spring tx provider - and >> bonecp for pooling), but the code could probably benefit from being >> defensive about attempting a rollback. This is an example of an exception I >> get: >> >> org.jooq.exception.DataAccessException: Cannot set autoCommit >> at >> org.jooq.impl.DefaultConnectionProvider.setAutoCommit(DefaultConnectionProvider.java:180) >> at >> org.jooq.impl.DefaultTransactionProvider.brace(DefaultTransactionProvider.java:185) >> at >> org.jooq.impl.DefaultTransactionProvider.rollback(DefaultTransactionProvider.java:167) >> at >> org.jooq.impl.DefaultDSLContext.transactionResult(DefaultDSLContext.java:311) >> at org.jooq.impl.DefaultDSLContext.transaction(DefaultDSLContext.java:326) >> at >> com.biblioboard.api.test.JooqNestedTransactionTest$TestService.outer(JooqNestedTransactionTest.java:30) >> at >> com.biblioboard.api.test.JooqNestedTransactionTest.testNestedTransaction(JooqNestedTransactionTest.java:55) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at >> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) >> at >> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) >> at >> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) >> at >> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) >> at >> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) >> at >> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) >> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) >> at >> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) >> at >> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) >> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) >> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) >> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) >> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) >> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) >> at org.junit.runners.ParentRunner.run(ParentRunner.java:309) >> at org.junit.runner.JUnitCore.run(JUnitCore.java:160) >> at >> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:74) >> at >> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:211) >> at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:67) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134) >> Caused by: java.sql.SQLException: Connection is closed! >> at >> com.jolbox.bonecp.ConnectionHandle.checkClosed(ConnectionHandle.java:459) >> at >> com.jolbox.bonecp.ConnectionHandle.setAutoCommit(ConnectionHandle.java:1290) >> at >> org.jooq.impl.DefaultConnectionProvider.setAutoCommit(DefaultConnectionProvider.java:177) >> ... 34 more >> >> It looks like a simple try/ catch where my breakpoint is here: >> http://screencast.com/t/RymVTaBgE should do the trick? >> >> Any idea why bonecp (or whatever it might be) would close/ return the >> connection on exceptions? >> >> Cheers, >> >> Eelco >> >> -- >> You received this message because you are subscribed to the Google Groups >> "jOOQ User Group" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
