WebSphere Application Server uses JDBC prepared statement caching as a performance enhancing feature. If you are using this feature together with DB2 for z/OS, be aware of the potential impact on the number of DB2 JDBC cursor objects available.
When you obtain a ResultSet object by running a PreparedStatement object, a DB2 JDBC cursor object is bound to it until the corresponding DB2 prepared statement is closed. This happens when the DB2 Connection object is released from the WebSphere Application Server connection pool. From an application perspective, the result set, prepared statement, and connection are each closed in turn. However, the underlying DB2 Connection is pooled by the WebSphere Application Server, the underlying DB2 PreparedStatement is cached by the application server, and each underlying DB2 JDBC cursor object associated with each ResultSet created on this PreparedStatement object is not yet freed.
Each PreparedStatement object in the cache can have one or more result sets associated with it. If a result set is opened and not closed, even though you close the connection, that result set is still associated with the prepared statement in the cache. Each of the result sets has a unique JDBC cursor attached to it. This cursor is kept by the statement and is not released until the prepared statement is cleared from the WebSphere Application Server cache.
java.sql.SQLException: DB2SQLJJDBCProfile Error: No more JDBC Cursors without hold
Some WebSphere Application Server tuning suggestions to help avoid this problem are: