[DERBY-5561] Race conditions in LogicalConnection checking for a null physical connection

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 10.5.3.2, 10.8.2.2
• Fix Version/s: 10.5.3.2, 10.6.2.4, 10.7.1.4, 10.8.3.0, 10.9.2.2
• Component/s: Network Client
• Environment: Solaris 10; Glassfish V2.1.1; ClientXADataSource connection pool
• Urgency: Urgent
• Issue & fix info: High Value Fix
• Bug behavior facts: Crash, Seen in production
• Assignee: Kristian Waagan
• Reporter: Brett Bergquist
• Created: 28/Dec/11 15:26
• Updated: 03/Sep/14 08:31
• Resolved: 01/Oct/12 14:41

Description

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.

Sub-Tasks

• Add test case for DERBY-5561 fix (Race conditions in LogicalConnection checking for a null physical connection): Open