Jaybird 2.1 JDBC driver Java Programmer's Manual - Firebird

• Compile the SQL statement into an internal BLR representation, save it in an
internal structure and assign a statement handle to a compiled statement.
• Execute the statement. First application checks whether the compiled statement
has any parameters and sets them if needed. After that statement is executed
using special call.
• Obtain results of the statement execution, for example number of updated rows
or a result set.
The obvious approach is to save the compiled statement and use it later. JDBC
specification already contains a java.sql.PreparedStatement interface exactly
for such purposes. Application prepares statement and uses it multiple times. This
approach works fine within the context of the same connection.
However, when connection pooling is used, application can no longer cache
prepared statements, since they are bound to the connection it obtained from the
pool. Application must close all prepared statements before giving connection
back to pool, but even if it does not do this, connection pool will perform this
automatically according to the JDBC specification. All advantages of the prepared
statements are undone – when application obtains next connection from the pool,
it must re-prepare statements.
Solution to the problem is to allow connection pool do statement pooling
internally. In this case all code remains compliant with the JDBC specification
saving all advantages of prepared statements.
Jaybird 2.1 connection pool has maxStatements property that controls the
behavior of the prepared statement pooling:
• If property is set to 0, no statement pooling is performed.
• If property is set to value n>0, connection pool will save maximum n
java.sql.PreparedStatement objects for the same SQL statement per
connection. Number of pooled PreparedStatement objects corresponding to
different SQL statements is not limited.
If application needs more prepared statements simultaneously (i.e. it prepares new
statement before releasing the one being currently in use), connection pool
transparently passes call to the connection object without pooling those
statements. In other words, the request to prepare statement is always satisfied
immediately, but only n prepared statements will remain pooled, rest will be
deallocated when PreparedStatement.close() method is called.
Following limitations apply:
• Firebird can have approx. 20.000 active statement handles per connection.
Additional care should be used when specifying the value of maxStatements
property.
• Neither java.sql.Statement nor java.sql.CallableStatement objects are
pooled.
• A compiled statement in Firebird contains references on database objects
(tables, views, procedures, etc.) needed to execute that SQL command. When
connection pool is used, those references are not released preventing any
structure modification of the database objects used in the SQL statement.
Chapter 4. Executing statements 42