db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bergquist, Brett" <BBergqu...@canoga.com>
Subject RE: [jira] [Commented] (DERBY-5561) Race conditions in LogicalConnection checking for a null physical connection
Date Wed, 28 Dec 2011 18:52:33 GMT
I have to get in the habit of putting the responses and stuff in the Jira.  I did not realize
that your message was from updating the Jira and just hit Reply.  I will be better in the
future but I am still an egg :)

-----Original Message-----
From: Kathey Marsden (Commented) (JIRA) [mailto:jira@apache.org] 
Sent: Wednesday, December 28, 2011 12:59 PM
To: derby-dev@db.apache.org
Subject: [jira] [Commented] (DERBY-5561) Race conditions in LogicalConnection checking for
a null physical connection


    [ https://issues.apache.org/jira/browse/DERBY-5561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13176727#comment-13176727
] 

Kathey Marsden commented on DERBY-5561:
---------------------------------------

Do you have multiple threads accessing the same  connection at the same time?   If so is it
intentional? Typically when that is being done it is not intentional as even if the various
methods were synchronized the two threads would share transaction and other state that would
be difficult to coordinate.


                
> 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
>
> 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

        

Mime
View raw message