getTransactionIsolation() in network client should not activate a transaction

• Key: DERBY-2084
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Bernt M. Johnsen
• Reporter: Bernt M. Johnsen
• Component/s: Network Client
• Affects Version/s: 10.1.3.1, 10.2.1.6, 10.3.1.4
• Fix Version/s: 10.1.3.2, 10.2.2.0, 10.3.1.4

Description

getTransactionIsolation() is implemented by means of
     rs = getTransactionIsolationStmt.executeQuery("values current isolation");

This will activate a transaction. Thus the code snippet

        Connection conn =
            DriverManager.getConnection(url);
        conn.setAutoCommit(false);
        int tx = conn.getTransactionIsolation();
        conn.close();

will fail with

java.sql.SQLException: Cannot close a connection while a transaction is still active.
        at org.apache.derby.client.am.SQLExceptionFactory.getSQLException(Unknown Source)
        at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source)
        at org.apache.derby.client.am.Connection.closeResourcesX(Unknown Source)
        at org.apache.derby.client.am.Connection.closeX(Unknown Source)
        at org.apache.derby.client.net.NetConnection.closeX(Unknown Source)
        at org.apache.derby.client.am.Connection.close(Unknown Source)
        at org.apache.derby.client.net.NetConnection.close(Unknown Source)
        at GetTransactionIsolation.test(GetTransactionIsolation.java:12)
        at GetTransactionIsolation.main(GetTransactionIsolation.java:22)
Caused by: org.apache.derby.client.am.SqlException: Cannot close a connection while a transaction is still active.
        at org.apache.derby.client.am.Connection.checkForTransactionInProgress(Unknown Source)
        ... 7 more

Comments

[Bernt M. Johnsen]

Only when autoc commit is false.

[Bernt M. Johnsen]

Simple patch uploaded.

[Bernt M. Johnsen]

This is a regression from 10.1.2.1 to 10.1.3.1 caused by the fix for DERBY-1148

[Deepa Remesh]

Bernt, I verified that your patch fixes the problem reported. I hadn't realized that the fix for DERBY-1148 would lead to this bug.

As an aside, I relooked at my patch for DERBY-1148. And I am wondering if the storing and saving of autocommit value is needed. I am checking if the below statement (and related statements) serve any purpose:
// Store the current auto-commit value and use it to restore
// at the end of this method.
boolean currentAutoCommit = autoCommit_;

I did some quick checks with and without these statements and seem to get same results. Any thoughts on this?

Semantically, it should make no difference if getTransactionIsolation() commited when autocommit==true, but I think the way it is now is working ok too.

[Daniel John Debrunner]

Bernt, sorry but I don't understand what your last comment is trying to say. "No difference" to whar?

[Bernt M. Johnsen]

Dan: It dosen't matter, since I was wrong.
Deepa: The current implementation is correct. You need to temporarily turn off autocommit because there may be open result-sets when getTransactionIsolation().

[Bernt M. Johnsen]

Committed revision 476087.

[Bernt M. Johnsen]

Merge to 10.2

[Bernt M. Johnsen]

Committed revision 476088.

[Bernt M. Johnsen]

Merge to 10.1

[Bernt M. Johnsen]

Moerged from trunk to 10.1.
Committed revision 476119.