JDBC Type 4 Driver 2.0 Programmer's Reference (SQL/MX 2.x)

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:
A run-time version of a table has a different redefinition timestamp than the compile-time version of the same
table.
❍
An existing open operation on a table was eliminated by a DDL or SQL utility operation.❍
The transaction isolation level and access mode at execution time is different from that at the compile time.❍
For more information on SQL/MX recompilation, see the SQL/MX Programming Manual for C and COBOL or the
SQL/MX Programming Manual for Java.
●
When a query is recompiled, the SQL/MX executor stores the recompiled query; therefore, the query is recompiled only
once until any of the previous conditions are met again.
●
The Type 4 driver pools the CallableStatement objects in the same way as PreparedStatement objects when
the statement pooling is activated.
●
The Type 4 driver does not cache Statement objects.●
Thread-safe SQL/MX Access
In the Type 4 driver, API layer classes are implemented as instance-specific objects to ensure thread safety:
SQLMXDataSource.getConnection() is implemented as a synchronized method to ensure thread safety in
getting a connection.
●
Once a connection is made, the connection object is instance-specific.●
If multiple statements are run on different threads in a single connection, statement objects are serialized to prevent data
corruption.
●
"Update ... Where Current of" Operations
The fetch size on a ResultSet must be 1 when performing an update ... where current of cursor SQL statement.
If the value of the fetch size is greater than 1, the result of the update ... where current of operation might be one of
the following:
An incorrect row might be updated based on the actual cursor position.
●
An SQLException might occur because the cursor being updated might have already been closed.●
Note: By default, the fetch size is 1.
The following is an example of setting a result set's fetch size to 1 and executing an update ... where current of
cursor SQL statement.
ResultSet rs;
...
rs.setFetchSize(1);
String st1 = rs.getCursorName();
Statement stmt2 = connection.createStatement( ResultSet.TYPE_FORWARD_ONLY