PQ72451: PREPAREDSTATEMENT IS NOT PROPERLY CLOSED IF DUPLICATE EXISTS USING WEBSPHERE PREPARED STATEMENT CACHE FEATURE | |||||||||||||||||||||||||||||||||||||||||||||
![]() |
|||||||||||||||||||||||||||||||||||||||||||||
![]() APAR status Closed as program error. Error description If two copies of the same PreparedStatement are prepared on a connection, without closing either statement, when these two statements are put into the WebSphere prepared statement cache, one of the statements will be placed in the cache, and the other statement will go out of scope without calling close. When the JVM finalizer thread invokes the finalizer on the prepared statement, it will be closed, however, large numbers of these duplicate statements can cause the finalizer thread to be overwhelmed, and cause the process memory to grow. The caching mechanism should be fixed such that when the duplicate statements are returned to the cache, one is closed, and the other is placed in the cache for reuse.Local fix Problem summary **************************************************************** * USERS AFFECTED: WebSphere Application Server users of * * prepared statement caching and prepare an * * SQL statement with the same SQL string more * * than once in a single transaction, and * * do not close the prepared statement * * between prepare API calls. * **************************************************************** * PROBLEM DESCRIPTION: WebSphere Users will notice that * * the application will continue * * to function normally, however * * the JVM memory footprint may * * continue to grow. * * * * If the customer then reviews * * a java heap dump, they will * * notice a large number of * * objects awaiting finalization. * **************************************************************** * RECOMMENDATION: * **************************************************************** The SQL string is the key for the prepared statement cache, allowing only one of the duplicate prepared statements to be preserved in the cache. The references to others are dropped without invoking the JDBC driver close method. This causes these statements to consume memory until JVM garbage collection occurs.Problem conclusion Customers should apply this APAR which will ensure the JDBC driver close method is called on the prepared statement in thisTemporary fix Customer was provided a test fix we believe will address the pr oblem.Comments
APAR is sysrouted FROM one or more of the following: APAR is sysrouted TO one or more of the following: Modules/Macros
Publications Referenced
|
Product categories: Software > Application Servers >
Distributed Application & Web Servers > WebSphere Application
Server > General
Operating system(s):
Software version: 00A
Software edition:
Reference #: PQ72451
IBM Group: Software Group
Modified date: Apr 7, 2003
(C) Copyright IBM Corporation 2000, 2008. All Rights Reserved.