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.
