[jira] [Updated] (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:all-tabpanel ] Mamta A. Satoor updated DERBY-5561: --- Fix Version/s: 10.6.2.3 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.5.3.2, 10.8.2.2 Environment: Solaris 10 Glassfish V2.1.1 ClientXADataSource connection pool Reporter: Brett Bergquist Assignee: Mamta A. Satoor Fix For: 10.6.2.3, 10.7.1.4, 10.8.2.3, 10.9.1.1 Attachments: derby-5561-2a-minor_cleanups.diff, DERBY-5561.patch 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 For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (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:all-tabpanel ] Kristian Waagan updated DERBY-5561: --- Backported to 10.7 with revision 1383996. I'll let the nightly tests run through before merging this fix back to 10.5, although I don't expect any problems. 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.5.3.2, 10.8.2.2 Environment: Solaris 10 Glassfish V2.1.1 ClientXADataSource connection pool Reporter: Brett Bergquist Assignee: Kristian Waagan Labels: derby_triage10_9 Fix For: 10.7.1.4, 10.8.2.3, 10.9.1.1 Attachments: derby-5561-2a-minor_cleanups.diff, DERBY-5561.patch 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 For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (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:all-tabpanel ] Kristian Waagan updated DERBY-5561: --- Fix Version/s: 10.7.1.4 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.5.3.2, 10.8.2.2 Environment: Solaris 10 Glassfish V2.1.1 ClientXADataSource connection pool Reporter: Brett Bergquist Assignee: Kristian Waagan Labels: derby_triage10_9 Fix For: 10.7.1.4, 10.8.2.3, 10.9.1.1 Attachments: derby-5561-2a-minor_cleanups.diff, DERBY-5561.patch 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 For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (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:all-tabpanel ] Kathey Marsden updated DERBY-5561: -- Labels: (was: derby_backport_reject_10_5) 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.5.3.2, 10.8.2.2 Environment: Solaris 10 Glassfish V2.1.1 ClientXADataSource connection pool Reporter: Brett Bergquist Assignee: Kristian Waagan Fix For: 10.7.1.4, 10.8.2.3, 10.9.1.1 Attachments: derby-5561-2a-minor_cleanups.diff, DERBY-5561.patch 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 For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (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:all-tabpanel ] Kathey Marsden updated DERBY-5561: -- Affects Version/s: 10.5.3.2 Likely applies to 10.5 as well so might be good to backport. 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.5.3.2, 10.8.2.2 Environment: Solaris 10 Glassfish V2.1.1 ClientXADataSource connection pool Reporter: Brett Bergquist Assignee: Brett Bergquist Labels: derby_triage10_9 Fix For: 10.8.2.3, 10.9.1.1 Attachments: derby-5561-2a-minor_cleanups.diff, DERBY-5561.patch 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 For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (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: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
[jira] [Updated] (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:all-tabpanel ] Kristian Waagan updated DERBY-5561: --- Attachment: derby-5561-2a-minor_cleanups.diff Attaching patch 2a, which cleans up a few minor issues: o converts docs to Javadoc o remove stale doc o correct/improve some comments o makes physicalConnection_ package-private o makes checkForNullPhysicalConnection final Patch ready for review. 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
[jira] [Updated] (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:all-tabpanel ] Kathey Marsden updated DERBY-5561: -- Issue fix info: High Value Fix,Patch Available Urgency: Urgent Labels: derby_triage10_9 (was: ) Triage for 10.9. Urgent, High Value Fix. Thanks Brett for the patch and Siddharth for picking up the testing and driving it to commit. 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 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
[jira] [Updated] (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:all-tabpanel ] Brett Bergquist updated DERBY-5561: --- Attachment: DERBY-5561.patch This patch changes all methods that call checkForNullPhysicalConnection to be synchronized. Some of the methods in LogicalConnection.java already were. This patch makes all calls consistent and eliminates the race condition. 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 Attachments: DERBY-5561.patch 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
