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

SQLException thrown when Connection.setAutoCommit(false) and then Connection.setAutoCommit(false); #15916

Closed
ssainz opened this issue Apr 8, 2021 · 2 comments · Fixed by #23453

Comments

@ssainz
Copy link

ssainz commented Apr 8, 2021

SQLException is thrown when :

      Class.forName(JDBC_DRIVER);
      con = DriverManager.getConnection(DB_URL, USER, PASS);

      con.setAutoCommit(false);
      con.setAutoCommit(true); // <--- Exception here

java.sql.SQLException: Connection is in auto-commit mode
at com.facebook.presto.jdbc.PrestoConnection.commit(PrestoConnection.java:173)
at com.facebook.presto.jdbc.PrestoConnection.setAutoCommit(PrestoConnection.java:155)
at presto_jdbc.main(presto_jdbc.java:34)

These sequence of operations are common in BI Tools. Expectation is that the second setAutoCommit(true) will commit any changes and then continue without exception.

@rogerbj
Copy link

rogerbj commented Jan 28, 2022

I agree with @ssainz.

@linghengqian
Copy link

Connection is in auto-commit mode
java.sql.SQLException: Connection is in auto-commit mode
	at com.facebook.presto.jdbc.PrestoConnection.commit(PrestoConnection.java:210)
	at com.facebook.presto.jdbc.PrestoConnection.setAutoCommit(PrestoConnection.java:192)
	at org.testcontainers.jdbc.ConnectionDelegate.setAutoCommit(ConnectionDelegate.java:11)
	at org.testcontainers.jdbc.ConnectionWrapper.setAutoCommit(ConnectionWrapper.java:6)
	at org.testcontainers.containers.PrestoContainerTest.testTcJdbcUri(PrestoContainerTest.java:142)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
	at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
	at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
	at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
	at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
	at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:112)
	at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
	at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:40)
	at org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:60)
	at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:52)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36)
	at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
	at org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:33)
	at org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:94)
	at jdk.proxy1/jdk.proxy1.$Proxy2.processTestClass(Unknown Source)
	at org.gradle.api.internal.tasks.testing.worker.TestWorker$2.run(TestWorker.java:176)
	at org.gradle.api.internal.tasks.testing.worker.TestWorker.executeAndMaintainThreadName(TestWorker.java:129)
	at org.gradle.api.internal.tasks.testing.worker.TestWorker.execute(TestWorker.java:100)
	at org.gradle.api.internal.tasks.testing.worker.TestWorker.execute(TestWorker.java:60)
	at org.gradle.process.internal.worker.child.ActionExecutionWorker.execute(ActionExecutionWorker.java:56)
	at org.gradle.process.internal.worker.child.SystemApplicationClassLoaderWorker.call(SystemApplicationClassLoaderWorker.java:113)
	at org.gradle.process.internal.worker.child.SystemApplicationClassLoaderWorker.call(SystemApplicationClassLoaderWorker.java:65)
	at worker.org.gradle.process.internal.worker.GradleWorkerMain.run(GradleWorkerMain.java:69)
	at worker.org.gradle.process.internal.worker.GradleWorkerMain.main(GradleWorkerMain.java:74)

rschlussel added a commit to rschlussel/presto that referenced this issue Aug 15, 2024
There was a bug where enabling autocommit when it had previously been
false would cause failure like:
java.sql.SQLException: Connection is in auto-commit mode

This was due to calling commit() from setAutoCommit() after autocommit
had already been changed to true.

Fixes prestodb#15916
rschlussel added a commit to rschlussel/presto that referenced this issue Aug 15, 2024
There was a bug where enabling autocommit when it had previously been
false would cause failure like:
java.sql.SQLException: Connection is in auto-commit mode

This was due to calling commit() from setAutoCommit() after autocommit
had already been changed to true.

Fixes prestodb#15916
rschlussel added a commit to rschlussel/presto that referenced this issue Aug 16, 2024
There was a bug where enabling autocommit when it had previously been
false would cause failure like:
java.sql.SQLException: Connection is in auto-commit mode

This was due to calling commit() from setAutoCommit() after autocommit
had already been changed to true.

Fixes prestodb#15916
tdcmeehan pushed a commit that referenced this issue Aug 16, 2024
There was a bug where enabling autocommit when it had previously been
false would cause failure like:
java.sql.SQLException: Connection is in auto-commit mode

This was due to calling commit() from setAutoCommit() after autocommit
had already been changed to true.

Fixes #15916
matt-calder pushed a commit to matt-calder/presto that referenced this issue Aug 20, 2024
There was a bug where enabling autocommit when it had previously been
false would cause failure like:
java.sql.SQLException: Connection is in auto-commit mode

This was due to calling commit() from setAutoCommit() after autocommit
had already been changed to true.

Fixes prestodb#15916
AbhijitKulkarni1 pushed a commit to intel-staging/presto that referenced this issue Oct 1, 2024
There was a bug where enabling autocommit when it had previously been
false would cause failure like:
java.sql.SQLException: Connection is in auto-commit mode

This was due to calling commit() from setAutoCommit() after autocommit
had already been changed to true.

Fixes prestodb#15916
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants