Dag H. Wanvik wrote:
"Bernt M. Johnsen" <[EMAIL PROTECTED]> writes:
Hi,
This behaviour is defined in the JDBC specification.
But Derby's statement cache works across connections, which alleviates
redundant statement compilation.
Please see http://db.apache.org/derby/docs/10.2/tuning/ctundepth29804.html
As Dag points out, Derby caches an internal object that represents all
the work necessary to compile a statement and it matches that object up
with executions of "prepared statements". This object does not go back
to the user. So while derby does cache this across connections to save
recompilation, and does share read-only parts of the plan, it does not
really cache the prepared statement object returned to the user.
The prepared statement object in jdbc is used to pass info back and
forth from the app and engine and thus is specific to the app and not
shared.
