Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <2051602399.1225121084339.JavaMail.jira@brutus>
Date: Mon, 27 Oct 2008 08:24:44 -0700 (PDT)
From: "Knut Anders Hatlen (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Resolved: (DERBY-3319) Logical connections do not check if a
 transaction is active on close
In-Reply-To: <16684247.1200408274447.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Knut Anders Hatlen resolved DERBY-3319.
---------------------------------------

    Resolution: Fixed

> 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
>             Fix For: 10.5.0.0
>
>         Attachments: d3319-1a.diff, d3319-1a.stat, LogicalConnectionCloseActiveTransactionBug.java, releaseNote.html
>
>
> 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.