JDBC Type 4 Driver Programmer's Reference for SQL/MX Release 3.1 (H06.23+, J06.12+)

the pooled connection, and not a new physical connection.
The connection pooling feature is available when the JDBC application uses either the DriverManager class or DataSource interface to obtain
a JDBC connection. The connection pool size is determined by the
maxPoolSize property value and minPoolSize property value.
By default, connection pooling is disabled. To enable connection pooling, set the maxPoolSize property to an integer value greater than 0
(zero).
Manage connection pooling by using the following Type 4 driver properties:
maxPoolSize
minPoolSize
initialPoolSize
maxStatements
When used with the DriverManager class, the Type 4 driver has a connection-pool manager that determines which connections are pooled
together by a unique value for the following combination of properties:
url
catalog
schema
username
password
blobTableName
clobTableName
serverDataSource
Therefore, connections that have the same values for the combination of a set of properties are pooled together.
Note: The connection-pooling property values used at the first connection of a given combination are effective
throughout the life of the process. An application cannot change any of these property values after the first
connection for a given combination.
Statement Pooling
Guidelines for Statement Pooling
Troubleshooting Statement Pooling
The statement pooling feature allows applications to reuse the PreparedStatement object in same way that they can reuse a connection in the
connection pooling environment. Statement pooling is done completely transparent to the application.
Guidelines for Statement Pooling
To enable statement pooling, set the maxStatements property to an integer value greater than 0 and enable connection pooling. See
Connection Pooling for more information.
Enabling statement pooling for your JDBC applications might dramatically improve the performance.
Explicitly close a prepared statement by using the Statement.close method because PreparedStatement objects that are not in scope are
also not reused unless the application explicitly closes them.
To ensure that your application reuses a PreparedStatement, call either of the following:
Statement.close method—called by the application
Connection.close method—called by the application. All the PreparedStatement objects that were in use are ready to be reused when
the connection is reused.
Troubleshooting Statement Pooling
Note the following Type 4 driver implementation details if you are troubleshooting statement pooling:
Type 4 driver looks for a matching PreparedStatement object in the statement pool and reuses the PreparedStatement. The matching
criteria include the SQL string, current catalog, current schema, current transaction isolation, and
resultSetHoldability. If the Type 4
driver
finds the matching PreparedStatement object, the driver returns the same PreparedStatement object to the application for reuse and
marks the
PreparedStatement object as in use.
The algorithm, "earlier used are the first to go," is used to make room for caching subsequently generated PreparedStatement objects when
the number of statements reaches the
maxStatements limit.
The Type 4 driver assumes that any SQL CONTROL statements in effect at the time of execution or reuse are the same as those in effect
at the time of SQL/MX compilation. If this condition is not true, reuse of a PreparedStatement object might result in unexpected behavior.
You should avoid SQL/MX recompilation to yield performance improvements from statement pooling. The SQL/MX executor automatically
recompiles queries when certain conditions are met. Some of these conditions are: