|
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 |
|
|
|
|
|
|