[Db-derby Wiki] Update of "StatementCache" by KnutAndersHatlen

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Db-derby Wiki" for change notification.

The "StatementCache" page has been changed by KnutAndersHatlen:
http://wiki.apache.org/db-derby/StatementCache?action=diff&rev1=2&rev2=3

- Derby caches prepared statements instances on a per-connection basis in the statement cache, to avoid the overhead of re-preparing the statements.
+ Derby caches prepared statements instances on a per-database basis in the statement cache, to avoid the overhead of re-preparing the statements.
  
  The statement cache can be disabled by setting {{{derby.language.statementCacheSize=0}}}, though this parameter is not currently documented ([[https://issues.apache.org/jira/browse/DERBY-4280|DERBY-4280]]).
  
@@ -16, +16 @@

  
  For another thing, the statement cache may cause us to need to recompile the statement at an awkward time, leading to deadlocks -- [[https://issues.apache.org/jira/browse/DERBY-4279|DERBY-4279]]
  
+ The cached statements can be shared between many java.sql.Statement (or !PreparedStatement or !CallableStatement) instances. Since the validity of the compiled plan is checked frequently during execution, and the plan is possibly shared between multiple threads, the monitor that guards the isValid field in !GenericPreparedStatement may become contended in multi-threaded scenarios and prevent multi-core scalability -- [[https://issues.apache.org/jira/browse/DERBY-3024|DERBY-3024]].
+