Issue Details (XML | Word | Printable)

Key: JDBC-359
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Mark Rotteveel
Reporter: Steffen Heil
Votes: 0
Watchers: 0

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

When the server fails (due to a full disk) the client can get into a NPE inside jaybird

Created: 10/Jul/14 01:56 PM   Updated: 30/Dec/14 12:00 PM
Component/s: Connection pool
Affects Version/s: Jaybird 2.2.5
Fix Version/s: Jaybird 2.2.6

Environment: java 1.7.0_55, firebird

 Description  « Hide
When the server disk was full, the firebird server process died and the client started to report NPEs instead of SQLExceptions.
We do have a jmap memory dump of that VM, pending reproduction.


| java.lang.NullPointerException
| at org.firebirdsql.jca.FBManagedConnection.internalCommit(
| at org.firebirdsql.jca.FBLocalTransaction.internalCommit(
| at org.firebirdsql.jca.FBLocalTransaction.commit(
| at org.firebirdsql.jdbc.InternalTransactionCoordinator$AutoCommitCoordinator.statementCompleted(
| at org.firebirdsql.jdbc.InternalTransactionCoordinator.statementCompleted(
| at org.firebirdsql.jdbc.AbstractStatement.notifyStatementCompleted(
| at org.firebirdsql.jdbc.AbstractPreparedStatement.notifyStatementCompleted(
| at org.firebirdsql.jdbc.AbstractStatement.notifyStatementCompleted(
| at org.firebirdsql.jdbc.AbstractPreparedStatement.executeUpdate(
| at sun.reflect.GeneratedMethodAccessor32.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(
| at java.lang.reflect.Method.invoke(
| at org.firebirdsql.pool.PooledPreparedStatementHandler.invoke(
| at org.firebirdsql.pool.$Proxy5.executeUpdate(Unknown Source)
| at

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Mark Rotteveel added a comment - 10/Jul/14 06:02 PM
This might be related to JDBC-350 and JDBC-357, but it could also be an independent problem.

Looking at the code when a fatal connection error occurs, the connection held within FBManagedConnection is 'destroyed' and then set to null. The sequence of events in this specific case seem to be:

1) attempt to commit
2) somewhere in the commit a GDSException is thrown
3) GDSException caught and forwarded to error listener which 'destroys' the connection and sets it to null
4) error caught in step 3 is rethrown
5) catch block from try around commit wants to rollback, but the connection is already null and causes a NullPointerException

Scheduled for 2.2.6

Mark Rotteveel added a comment - 11/Jul/14 05:10 PM
Replaced most direct uses of gdsHelper with a call to getGDSHelper() that checks for null and otherwise throws a GDSException (2.2.x) or SQLException (3.0). In the cases where that is not an option, I added an extra null check.

For 3.0 I will probably revisit this code for a more thorough refactoring when I remove the remnants of the old protocol implementation.