[jira] Updated: (DERBY-4607) HeapScan test commits wrong connection

["Knut Anders Hatlen (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/DERBY-4607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Knut Anders Hatlen updated DERBY-4607:
--------------------------------------

    Attachment: commit.diff

Attached is a patch that makes setUp() initialize the select statement with the helper method BaseJDBCTestCase.prepareStatement() in HeapScan and its sub-class CoveredIdxScan. The helper method uses the getConnection() method to obtain the connection, so now the calls to getConnection().commit() commit on the correct connection. Using the helper method also removes the need to close the statement explicitly in tearDown(). Also, getConnection().commit() was simplified to commit() (helper in BaseJDBCTestCase) which does the same thing.

The patch doesn't appear change the results of the tests in any noticeable way. This is as expected, since there shouldn't be much work required on commit for read-only transactions with read committed isolation level (no log records to flush, and all locks should have been released prior to commit).

> HeapScan test commits wrong connection
> --------------------------------------
>
>                 Key: DERBY-4607
>                 URL: https://issues.apache.org/jira/browse/DERBY-4607
>             Project: Derby
>          Issue Type: Bug
>          Components: Test
>    Affects Versions: 10.6.0.0
>            Reporter: Knut Anders Hatlen
>            Assignee: Knut Anders Hatlen
>            Priority: Minor
>         Attachments: commit.diff
>
>
> The SELECT query in HeapScan is initialized like this:
>         select = openDefaultConnection().prepareStatement("SELECT * FROM "+tableName);
> The test cases commit the transaction like this:
>         getConnection().commit();
> openDefaultConnection() opens and returns a new connection to the default database, whereas getConnection() returns a cached default connection, so the two connections are not the same, and the transaction that's being committed is not the executing transaction.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.