Using the statement cache

The statement cache is enabled by default. You can use it to avoid extra compilation overhead: Derby supports the ParameterMetaData interface, new in JDBC 3.0. This interface describes the number, type, and properties of prepared statement parameters. See the Derby Developer's Guide for more information.
Figure 1. A connection need only compile a PreparedStatement once. Subsequent executions can use the same statement execution plan even if the parameter values are different. (PreparedStatements are not shared across connections.)
This figure shows one connection
with multiple executions of the same PreparedStatement, which uses the same
statement execution plan.
Remember: If your application executes statements that are almost but not exactly alike, it is more efficient to use PreparedStatements with dynamic or IN parameters.
Figure 2. A database can reuse a statement execution plan when the SQL text matches a prior statement exactly. (PreparedStatements are much more efficient.)
This figure
shows how Derby can reuse a statement execution plan that is already in the
statement cache, even when the statement is executed from a different connection.