Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Mon, 7 May 2012 08:37:51 +0000 (UTC)
From: "Kristian Waagan (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: 
 <1106097674.33461.1336379871588.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1008737819.48689.1325086110673.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Updated] (DERBY-5561) Race conditions in LogicalConnection
 checking for a null physical connection
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Kristian Waagan updated DERBY-5561:
-----------------------------------

    Issue & fix info: High Value Fix  (was: Patch Available,High Value Fix)

I committed patch 2a to trunk with revision 1334919.
I'll give it a week or so before I look at backporting this to 10.8.
                
> Race conditions in LogicalConnection checking for a null physical connection
> ----------------------------------------------------------------------------
>
>                 Key: DERBY-5561
>                 URL: https://issues.apache.org/jira/browse/DERBY-5561
>             Project: Derby
>          Issue Type: Bug
>          Components: Network Client
>    Affects Versions: 10.8.2.2
>         Environment: Solaris 10
> Glassfish V2.1.1
> ClientXADataSource connection pool
>            Reporter: Brett Bergquist
>            Assignee: Siddharth Srivastava
>              Labels: derby_triage10_9
>         Attachments: DERBY-5561.patch, derby-5561-2a-minor_cleanups.diff
>
>
> There are race conditions with checkForNullPhysicalConnection calls in LogicalConnection.  checkForNullPhysicalConnection is not synchronized and it checks for the member "phsyicalConnection" which can be cleared by "nullPhsyicalConnection" (which is synchronized) and "close" (which is synchronized) and "closeWithoutRecyclingToPool" (which is synchronized).
> This affects "nativeSQL", "getAutoCommit", "getTransactionIsolation", "getWarnings", "isReadOnly", "getCatalog", "getTypeMap", "createStatement", "prepareCall", "prepareStatement", "setHoldability", "getHoldability", "setSavePoint", "rollBack", "releaseSavePoint", "getSchema", "setSchema".
> All of these call "checkForNullPhysicalConnection" and then use the member "physicalConnection" after that call returns.  Because these methods are not synchronized, between the time "checkForNullPhysicalConnectoin" returns and "physicalConnection" is used, the "physicalConnection" member could be set to null and then a NPE occurs.
> Probably all of these methods should be changed to synchronized.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira