Re: transaction handling eats exceptions
This is now fixed on GitHub master. Thanks again for reporting! Lukas 2014-10-29 15:50 GMT+01:00 Lukas Eder lukas.e...@gmail.com: 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 eelco.hillen...@gmail.com: 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 jooq-user+unsubscr...@googlegroups.com. 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
Re: transaction handling eats exceptions
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 eelco.hillen...@gmail.com: 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 jooq-user+unsubscr...@googlegroups.com. 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 jooq-user+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
transaction handling eats exceptions
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 jooq-user+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
