Native memory allocations with database connection objects
 Technote (troubleshooting)
 
Problem(Abstract)
Questions on native memory allocations with database connection objects and prepared statement cache usage.
 
Resolving the problem
Q1: 1. How and when database connection object is allocated on native memory and how and when it will be released?
A1: The database connection object is allocated in native memory when the
getConnection command is executed, assuming there are no connections available in the pool to fulfill the request. Additional native objects will be allocated as statements are executed, and result sets created, this memory should be freed when those objects are closed.

Q2: If prepared statement cache is used, how and when the cache
is allocated on the memory?

A2: If prepared statement caching is enabled, the memory is allocated when new statements are created. Each connection has its own prepared statement cache, which at initialization consumes no native memory, and a tiny amount of Java memory. When a prepared statement is created in the customer code, we first check to see if it is in the cache to be reused. If not, we create the object, which causes consumption of memory. When the application calls close() on the statement, we put it in the cache for reuse, if we have reached the max size of the cache, we push out the least recently used statement. This is why tuning of your cache size is very important. Too small and statements are pushed out frequently, causing little performance benefit of using prepared statement cache. Too large and the large memory consumption causes out of memory errors.
 
 
Cross Reference information
Segment Product Component Platform Version Edition
Application Servers Runtimes for Java Technology Java SDK
 
 


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server
Operating system(s): Windows
Software version: 6.0
Software edition:
Reference #: 1226498
IBM Group: Software Group
Modified date: Dec 27, 2005