Issue Details (XML | Word | Printable)

Key: JDBC-313
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Mark Rotteveel
Reporter: Mark Rotteveel
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Jaybird JCA/JDBC Driver

Database handle not always invalidated + missing checks on invalid handle

Created: 19/Jun/13 07:05 AM   Updated: 02/Nov/13 12:16 PM
Component/s: JDBC driver, JNI layer, Wire protocol
Affects Version/s: Jaybird 2.1.6, Jaybird 2.2, Jaybird 2.2.1, Jaybird 2.2.2, Jaybird 2.2.3
Fix Version/s: Jaybird 2.2.4

Time Tracking:
Issue & Sub-Tasks
Issue Only
Not Specified

Sub-Tasks  All   Open   

 Description  « Hide
Not all areas of Jaybird check for database handle validity before continuing with an action that uses the database. An example of such problem is a NullPointerException in iscDatabaseInfo; See also Stackoverflow question http://stackoverflow.com/questions/17160036/error-using-jaybird-and-android

Looking at the code, the direct cause is a missing check on the handle validity. But a deeper look shows that the wire protocol implementation does not properly invalidate the handle, so even if it would have checked for validity before the action, the NPE would still have occurred.

Actions:
* Ensure invalidateHandle() is called when the connection is closed
* Add validity checks in all actions



 All   Comments   Work Log   Change History   Version Control   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Mark Rotteveel added a comment - 19/Jun/13 07:06 AM
Scheduled for 2.2.4, and 2.3 (although the new wireprotocol implementation will make that irrelevant).

Mark Rotteveel added a comment - 22/Jun/13 08:20 AM
My assertion that the handle wasn't always invalidated was incorrect. I made validation of database, transaction, statement, blob and service handles more consistent for 2.2.4.

I am not going to port this to 2.3, as the new implementation works differently, I will keep this issue open as a reminder to thoroughly check this in the new implementation in 2.3.