[jira] Updated: (DERBY-3319) Logical connections do not check if a transaction is active on close

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

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

Knut Anders Hatlen updated DERBY-3319:
--------------------------------------

    Attachment: d3319-1a.stat
                d3319-1a.diff

Here's a patch that changes the behaviour as described in the previous
comment. The patch touches the following files:

Embedded:

M      java/engine/org/apache/derby/impl/jdbc/EmbedConnection.java

  - factored out code to check for active transaction in close() so
    that it can be used in EmbedPooledConnection too

M      java/engine/org/apache/derby/iapi/jdbc/BrokeredConnectionControl.java

  - new interface method to check if it is allowed to close a brokered
    connection (checkClose())

M      java/engine/org/apache/derby/jdbc/EmbedPooledConnection.java

  - implementation of BrokeredConnectionControl.checkClose()

  - in getConnection(), reset the physical connection before closing
    the existing logical connection, so that an exception isn't thrown
    if the logical connection is still active

M      java/engine/org/apache/derby/jdbc/EmbedXAConnection.java

  - factored out common code to check if the transaction is global
    into a helper method (isGlobal())

  - implementation of BrokeredConnectionControl.checkClose()

M      java/engine/org/apache/derby/iapi/jdbc/BrokeredConnection.java

  - use BrokeredConnectionControl.checkClose() in close() to get the
    expected exception when the transaction is active

Client:

M      java/client/org/apache/derby/client/net/NetConnection.java

  - fixed existing method (allowCloseInUOW_()) for checking if the
    connection can be closed in unit of work (previously is always
    returned false)

M      java/client/org/apache/derby/client/am/Connection.java

  - transactionInProgress(): check NetConnection.allowCloseInUOW_()
    instead of the autoCommit_ flag to find out if a transaction in
    progress prevents us from closing the connection. Without this
    change, XAConnection.getConnection() thinks that it needs to roll
    back active global XA transactions, which it is not allowed to do.

  - checkForTransactionInProgress(): don't check allowCloseInUOW_()
    since it is now checked in transactionInProgress()

M      java/client/org/apache/derby/client/am/LogicalConnection.java

  - call checkForTransactionInProgress() from close() to get the
    expected exception when the transaction is active

Tests:

M      java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/StatementPoolingTest.java

  - enabled the test case that had been disabled because of this issue

  - fixed two occurrences of connections being closed with active
    transactions

M      java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/J2EEDataSourceTest.java

  - test cases for close of active connections with all combinations of
    { auto-commit, no auto-commit } ×
    { DataSource, ConnectionPoolDS, local XADataSource, global XADataSource} ×
    { client, embedded }


All the regression tests passed, except for the wisconsin test, which
passed on rerun.

> Logical connections do not check if a transaction is active on close
> --------------------------------------------------------------------
>
>                 Key: DERBY-3319
>                 URL: https://issues.apache.org/jira/browse/DERBY-3319
>             Project: Derby
>          Issue Type: Bug
>          Components: JDBC, Network Client
>    Affects Versions: 10.3.2.1, 10.4.1.3, 10.5.0.0
>         Environment: Embedded driver and client driver.
>            Reporter: Kristian Waagan
>            Assignee: Knut Anders Hatlen
>         Attachments: d3319-1a.diff, d3319-1a.stat, LogicalConnectionCloseActiveTransactionBug.java
>
>
> If you call close on a logical connection, for instance as obtained through a PooledConnection, it does not check if there is an active transaction.
> The close of the logical connection is allowed, and even the close of the parent PooledConnection is allowed in the client driver. This can/will cause resources to be left on the server, and later operations might fail (typically with lock timeouts because the "closed" transaction is still holding locks).
> I do not know if gc will solve this eventually, but I would say the current behavior of the client driver is wrong in any case.
> There is difference in the behavior between the embedded and the client driver, and there also seems to be a bug in the embedded driver.
> The analysis above is a bit sketchy, so it might be required to look into the issue a bit more...
> I will attach a repro (JDBC usage should be verified as well, is it legal / as intended?)

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