Information provided in SQL Exceptions
Derby Developer's Guide
90
· If a thread is interrupted and the interrupt status flag is not cleared before entering
a Derby JDBC call, or if the thread is interrupted while inside a Derby JDBC call,
the connection that is experiencing the interrupt will be terminated in the following
situations:
· If a query fetches rows from a database table after the interrupt has occurred
· If the execution of a new element in a batched statement is attempted after the
interrupt has occurred
· If an interrupt is received while a transaction is waiting for a lock
If the connection is terminated, the application thread will experience the following
consequences:
· The JDBC call will raise an SQLException with state "08000" ("Connection
closed by unknown interrupt").
· Outstanding transactional work on that connection will be rolled back, and all
of its locks will be released.
· The connection cannot be used to execute any further JDBC calls.
On return from the JDBC call, the Thread.isInterrupted() method of the thread will
return true, whether or not an exception terminating the connection was thrown.
That is, even if Derby does not heed an interrupt, the flag will remain set on exit
from the JDBC call.
· All other connections will remain open. This includes other connections which the
interrupted thread may be using. These connections will remain open at least until
the thread tries to use one of its other connections. If the thead has neglected to
clear its interrupted status flag, this connection is also subject to termination as
described above.
· The application should normally be prepared to catch the 08000 exceptions, discard
the dead connection, clear the interrupted status of the thread, and then restart the
transaction in a new connection.
Working with Derby SQLExceptions in an application
JDBC generates exceptions of the type java.sql.SQLException. If your application
runs on JDK 1.6 or higher, the exceptions will be the refined subtypes of
java.sql.SQLException introduced by JDBC4. To see the exceptions generated by Derby,
retrieve and process the
SQLExceptions
in a catch block.
Information provided in SQL Exceptions
Derby provides the message, SQLState values, and error codes in SQL exceptions.
Use the
getSQLState
and
getMessage
methods to view the
SQLState
and error
messages. Use
getErrorCode
to see the error code. The error code defines the
severity of the error and is not unique to each exception.
Note: Severity is not standardized in Derby. Applications should not depend on the
severity returned from SQL exceptions.
Applications should also check for and process java.sql.SQLWarnings, which are
processed in a similar way. Derby issues an
SQLWarning
if the
create=true
attribute
is specified and the database already exists.
Example of processing SQLExceptions
A single error can generate more than one SQLException. Use a loop and the
getNextException
method to process all
SQLExceptions
in the chain. In many
cases, the second exception in the chain is the pertinent one.
The following is an example:
