InfoCenter Home >
4: Developing applications >
4.2: Building Web applications >
4.2.4: Putting it all together (Web applications) >
4.2.4.2: Obtaining and using database connections >
4.2.4.2.1: Accessing data with the JDBC 2.0 Optional Package APIs >
4.2.4.2.1.3: Handling data access exceptions

4.2.4.2.1.3: Handling data access exceptions

For data access, the standard Java exception class to catch is java.sql.SQLException. IBM WebSphere Application Server monitors for specific SQL exceptions thrown from the database. Several of these exceptions are mapped to WebSphere-specific exceptions. The product provides WebSphere-specific exceptions to ease development by not requiring you to know all of the database-specific SQL exceptions that could be thrown in typical situations. In addition, monitoring SQL exceptions enables the product and application to recover from common problems like intermittent network or database outages.

ConnectionWaitTimeoutException

This exception (com.ibm.ejs.cm.pool.ConnectionWaitTimeoutException) indicates that the application has waited for the connectionTimeout (CONN_TIMEOUT) number of seconds and has not been returned a connection. This can occur when the pool is at its maximum size and all of the connections are in use by other applications for the duration of the wait. In addition, there are no connections currently in use that the application can share, because either the user ID and password are different or it is in a different transaction. The following code fragment shows how to use this exception:

java.sql.Connection conn = null;
javax.sql.DataSource ds = null;
...
try {
// Retrieve a DataSource through the JNDI Naming Service

java.util.Properties parms = new java.util.Properties();
setProperty.put(Context.INITIAL_CONTEXT_FACTORY,
"com.ibm.websphere.naming.WsnInitialContextFactory");

// Create the Initial Naming Context
javax.naming.Context ctx = new
javax.naming.InitialContext(parms);

// Lookup through the naming service to retrieve a DataSource object
javax.sql.DataSource ds =
(javax.sql.DataSource)ctx.lookup("jdbc/SampleDB");

conn = ds.getConnection();
// work on connection
}
catch (com.ibm.ejs.cm.pool.ConnectionWaitTimeoutException cw) {
// notify the user that the system could not provide a
// connection to the database
}
catch (java.sql.SQLException sqle) {
// deal with exception
}

In all cases in which the ConnectionWaitTimeoutException is caught, there is very little to do in terms of recovery. It usually doesn't make sense to retry the getConnection() method, because if a longer wait time is required, the connectionTimeout datasource property should be set higher. Therefore, if this exception is caught by the application, the administrator should review the expected usage of the application and tune the connection pool and the database accordingly.

StaleConnectionException

This exception (com.ibm.ejs.cm.portability.StaleConnectionException) indicates that the connection currently being held is no longer valid. This can occur for numerous reasons, including:

  • The application fails to get a connection because of a problem such as the database not being started.
  • A connection is no longer usable because of a database failure. When an application tries to use a connection it previously obtained, the connection is no longer valid. In this case, all connections currently in use by the application may prompt this exception.
  • The application using the connection has already called close() and then tries to use the connection again.
  • The connection has been orphaned, and the application tries to use the orphaned connection.
  • The application tries to use a JDBC resource, such as Statement, obtained on a now-stale connection.

When application code catches StaleConnectionException, it should take explicit steps to handle the exception. StaleConnectionException extends SQLException, so it can be thrown from any method that is declared to throw SQLException. The most common occasion for a StaleConnectionException to be thrown is the first time a connection is used, just after it has been retrieved. Because connections are pooled, a database failure is not detected until the operation immediately following its retrieval from the pool, which is the first time communication with the database is attempted. It is only when a failure is detected that the connection is marked stale. StaleConnectionException occurs less often if each method that accesses the database gets a new connection from the pool. Typically, this occurs because all connections currently allocated to an application are marked stale; the more connections the application has, the more connections can be stale.

Generally, when a StaleConnectionException is caught, the transaction in which the connection was involved needs to be rolled back and a new transaction begun with a new connection.

For more information and detailed code samples, be sure to read the IBM whitepaper to be published on the Web during the summer of 2001.

Go to previous article: Tips for using connection pooling Go to next article: Accessing data with the JDBC 1.0 reference model

 

 
Go to previous article: Tips for using connection pooling Go to next article: Accessing data with the JDBC 1.0 reference model