Fix rollback in auto-commit mode and handle numeric autocommit responses

[vikrantpuppala]

Summary

• rollback() now throws DatabricksTransactionException when called while the connection is in auto-commit mode (no active transaction), aligning behavior with the JDBC spec
• fetchAutoCommitStateFromServer() now accepts both "1"/"0" and "true"/"false" responses from the SET AUTOCOMMIT query, since different server implementations return different formats
• Updated E2E and unit tests to reflect the corrected behavior

Context

1. connection.rollback() in auto-commit mode should throw an exception, not silently succeed
2. SET AUTOCOMMIT query returns "1"/"0" rather than "true"/"false" depending on the server

Test plan

• Unit tests pass: DatabricksConnectionTest (42/42 pass)
• E2E tests: TransactionTests and ExplicitTransactionStatementTests against staging warehouse

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Aligns the driver’s transaction/autocommit behavior with JDBC spec by making rollback() invalid in auto-commit mode and by tolerating numeric ("1"/"0") autocommit state responses from SET AUTOCOMMIT.

Changes:

• Make DatabricksConnection.rollback() throw in auto-commit mode (no active transaction).
• Update server autocommit state parsing to accept "true"/"false" and "1"/"0".
• Adjust unit + E2E tests for the updated rollback/autocommit behavior.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

File	Description
src/main/java/com/databricks/jdbc/api/impl/DatabricksConnection.java	Update autocommit state parsing; change rollback behavior to throw in auto-commit mode.
src/test/java/com/databricks/jdbc/api/impl/DatabricksConnectionTest.java	Update rollback tests; add unit tests for numeric autocommit server responses.
src/test/java/com/databricks/jdbc/integration/e2e/TransactionTests.java	Update E2E rollback-without-transaction expectation to throwing behavior.
src/test/java/com/databricks/jdbc/integration/e2e/ExplicitTransactionStatementTests.java	Update E2E assertion to accept numeric autocommit query results.

Comments suppressed due to low confidence (1)

src/main/java/com/databricks/jdbc/api/impl/DatabricksConnection.java:267

• fetchAutoCommitStateFromServer() only closes the ResultSet in the rs.next() success path. If the query returns no rows (or throws after executeQuery succeeds), the ResultSet is never closed, which can leak server resources. Use try-with-resources for the ResultSet (and ideally the Statement) or ensure rs.close() happens in a finally.

      ResultSet rs = statement.executeQuery("SET AUTOCOMMIT");

      if (rs.next()) {
        // The result may contain "true"/"false" or "1"/"0" depending on the server
        String value = rs.getString(1); // Column 1: value

        LOGGER.debug(
            "Fetched autoCommit state from server: value={}. Updating session cache.", value);

        boolean autoCommitState = "true".equalsIgnoreCase(value) || "1".equals(value);

        // Update the session cache with the server value
        session.setAutoCommit(autoCommitState);

        rs.close();
        return autoCommitState;

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The PR description says rollback() should throw DatabricksTransactionException in auto-commit mode, but this test only asserts SQLException. Using the specific exception type here (like the COMMIT test does) would better lock in the intended contract and catch regressions where rollback starts throwing a different SQLException subclass.

Suggested change

	SQLException exception =
	assertThrows(
	SQLException.class,
	DatabricksTransactionException exception =
	assertThrows(
	DatabricksTransactionException.class,

[gopalldb]

can we update the javadoc now? In fact we should rely on JDBC spec javadoc.

[gopalldb]

it means that even values like "yes" or "enabled" would result in false. I think, can we explicitly throw error in those cases instead of blindly treating those as false? Not blocker for this PR though

[gopalldb]

LG, some minor comments, at least fix javadoc comment before merge