You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-commits@db.apache.org by ch...@apache.org on 2011/04/08 22:40:01 UTC
svn commit: r1090436 - in /db/derby/docs/trunk/src: devguide/ tuning/
Author: chaase3
Date: Fri Apr 8 20:40:00 2011
New Revision: 1090436
URL: http://svn.apache.org/viewvc?rev=1090436&view=rev
Log:
DERBY-5171 Fix uses of <alt> and <desc> elements and figure captions
Modified 9 files in 2 manuals.
Patches: DERBY-5171.diff
Modified:
db/derby/docs/trunk/src/devguide/cdevconcepts16400.dita
db/derby/docs/trunk/src/devguide/cdevconcepts28436.dita
db/derby/docs/trunk/src/devguide/cdevcsecure42374.dita
db/derby/docs/trunk/src/devguide/cdevcsecuree.dita
db/derby/docs/trunk/src/devguide/cdevdeploy855368.dita
db/derby/docs/trunk/src/devguide/cdevdeploy855655.dita
db/derby/docs/trunk/src/devguide/cdevdvlp27610.dita
db/derby/docs/trunk/src/devguide/cdevdvlp40724.dita
db/derby/docs/trunk/src/tuning/ctundepth32379.dita
Modified: db/derby/docs/trunk/src/devguide/cdevconcepts16400.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/devguide/cdevconcepts16400.dita?rev=1090436&r1=1090435&r2=1090436&view=diff
==============================================================================
--- db/derby/docs/trunk/src/devguide/cdevconcepts16400.dita (original)
+++ db/derby/docs/trunk/src/devguide/cdevconcepts16400.dita Fri Apr 8 20:40:00 2011
@@ -41,27 +41,29 @@ any deadlock checking.</p>
set to 60 seconds. -1 is the equivalent of no wait timeout. This means that
transactions never time out, although <ph conref="../conrefs.dita#prod/productshortname"></ph> can
choose a transaction as a deadlock victim.</p>
-<fig expanse="column" id="cdevconcepts27089"><title>One possible configuration:
-deadlock checking occurs when a transaction has waited 30 seconds; no lock
-wait timeouts occur.</title>
-<image href="lockwa3.gif" placement="break"><alt>This figure shows a configuration
-where deadlock checking occurs when a transaction has waited 30 seconds. No
-lock wait timeouts occur.</alt></image>
+<p>In the following figure, <codeph><i>derby.locks.deadlockTimeout</i></codeph>
+is set to 30 seconds, while <codeph><i>derby.locks.waitTimeout</i></codeph> has
+no limit.</p>
+<fig expanse="column" id="cdevconcepts27089"><title>Configuration with
+deadlock checking after 30 seconds and no lock wait timeouts</title>
+<image href="lockwa3.gif" placement="break"><alt>This figure shows a configuration in which transactions are never aborted unless they are selected as the victim when deadlocks are checked. If at 30 seconds there is no deadlock, the transaction will wait until it can obtain a lock (or forever).</alt>
+</image>
</fig>
-<fig expanse="column" id="cdevconcepts91443"><title>Another typical configuration:
-deadlock checking occurs after a transaction has waited 60 seconds for a lock;
-after 90 seconds, the transaction times out and is rolled back. </title>
-<image href="lockwa1.gif" placement="break"><alt>This figure shows a configuration
-where deadlock checking occurs after a transaction has waited 60 seconds for
-a lock. After 90 seconds, the transaction times out and is rolled back.</alt>
+<p>In the following figure, <codeph><i>derby.locks.deadlockTimeout</i></codeph>
+is set to 60 seconds, while <codeph><i>derby.locks.waitTimeout</i></codeph> is
+set to 90 seconds.</p>
+<fig expanse="column" id="cdevconcepts91443"><title>Configuration with
+deadlock checking after 60 seconds and lock wait timeout at 90 seconds</title>
+<image href="lockwa1.gif" placement="break"><alt>This figure shows a configuration where deadlock checking occurs after a transaction has waited 60 seconds for a lock. After it has waited for 90 seconds, the transaction times out and is rolled back.</alt>
</image>
</fig>
-<fig expanse="column" id="cdevconcepts14875"><title>A configuration in which
-no deadlock checking occurs: transactions time out after they have waited
-50 seconds. No deadlock checking occurs. </title>
-<image href="lockwa2.gif" placement="break"><alt>This figure shows a configuration
-where no deadlock checking occurs. The transactions time out after they have
-waited 50 seconds. No deadlock checking occurs.</alt></image>
+<p>In the following figure, <codeph><i>derby.locks.deadlockTimeout</i></codeph>
+is set to 60 seconds, while <codeph><i>derby.locks.waitTimeout</i></codeph> is
+set to 50 seconds, lower than the deadlock timeout limit.</p>
+<fig expanse="column" id="cdevconcepts14875"><title>Configuration with
+no deadlock checking and a 50-second lock wait timeout</title>
+<image href="lockwa2.gif" placement="break"><alt>This figure shows a configuration where no deadlock checking occurs. The transactions time out after they have waited 50 seconds.</alt>
+</image>
</fig>
</conbody>
</concept>
Modified: db/derby/docs/trunk/src/devguide/cdevconcepts28436.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/devguide/cdevconcepts28436.dita?rev=1090436&r1=1090435&r2=1090436&view=diff
==============================================================================
--- db/derby/docs/trunk/src/devguide/cdevconcepts28436.dita (original)
+++ db/derby/docs/trunk/src/devguide/cdevconcepts28436.dita Fri Apr 8 20:40:00 2011
@@ -34,13 +34,12 @@ the rows in the <i>Accounts</i> table he
cannot complete its transaction because of the lock on <i>Orders</i>. Transaction
B cannot complete its transaction because of the lock on <i>Accounts</i>.
All activity comes to a halt and remains at a standstill forever unless the
-DBMS detects the deadlock and aborts one of the transactions.</p>
+DBMS detects the deadlock and aborts one of the transactions. The following
+figure shows this situation.</p>
<fig expanse="column"><title>A deadlock where two transactions are waiting
-for one another to give up locks.</title>
-<image href="dead.gif" placement="break"><alt>This figure depicts a deadlock.
-Transaction A has a lock on the Accounts table and needs a lock on the Orders
-table to finish the transaction. Transaction B has a lock on the Orders table
-and needs a lock on the Accounts table to finish the transaction.</alt></image>
+for one another to give up locks</title>
+<image href="dead.gif" placement="break"><alt>This figure depicts a deadlock. Transaction A has a lock on the Accounts table and needs a lock on the Orders table to finish the transaction. Transaction B has a lock on the Orders table and needs a lock on the Accounts table to finish the transaction.</alt>
+</image>
</fig>
</conbody>
</concept>
Modified: db/derby/docs/trunk/src/devguide/cdevcsecure42374.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/devguide/cdevcsecure42374.dita?rev=1090436&r1=1090435&r2=1090436&view=diff
==============================================================================
--- db/derby/docs/trunk/src/devguide/cdevcsecure42374.dita (original)
+++ db/derby/docs/trunk/src/devguide/cdevcsecure42374.dita Fri Apr 8 20:40:00 2011
@@ -56,13 +56,13 @@ entire system, depending on whether you
<p>When <ph conref="../conrefs.dita#prod/productshortname"></ph> user authentication
is enabled and <ph conref="../conrefs.dita#prod/productshortname"></ph> uses
an external directory service, the architecture looks something like that
-shown in the figure below. </p>
-<fig expanse="column" id="cdevcsecure32704"><title><ph conref="../conrefs.dita#prod/productshortname"></ph> user
-authentication using an external service. The application can be a single-user
-application with an embedded <ph conref="../conrefs.dita#prod/productshortname"></ph> engine
-or a multi-user application server.</title>
-<image href="authentic_os.gif" placement="break"><alt>This figure shows Derby
-handling user authentication using an external service. </alt></image>
+shown in the following figure. The application can be a single-user application with
+an embedded <ph conref="../conrefs.dita#prod/productshortname"></ph> engine
+or a multi-user application server.</p>
+<fig expanse="column" id="cdevcsecure32704"><title><ph conref="../conrefs.dita#prod/productshortname"></ph>
+user authentication using an external service</title>
+<image href="authentic_os.gif" placement="break"><alt>This figure shows how an application passes Derby user authentication through an external directory service before access to a Derby database is allowed.</alt>
+</image>
</fig>
<p><ph conref="../conrefs.dita#prod/productshortname"></ph> always runs embedded
in another Java application, whether that application is a single-user application
@@ -70,13 +70,13 @@ or a multiple-user application server or
<p>A database can be accessed by only one JVM at a time, so it is possible
to deploy a system in which the application in which <ph conref="../conrefs.dita#prod/productshortname"></ph> is
embedded, not <ph conref="../conrefs.dita#prod/productshortname"></ph>, handles
-the user authentication by connecting to an external directory service. </p>
-<fig expanse="column"><title>The application provides the user authentication
-using an external service. The application can be a single-user application
-with an embedded <ph conref="../conrefs.dita#prod/productshortname"></ph> engine
-or a multi-user application server.</title>
-<image href="appauth_os.gif" placement="break"><alt>This figure shows the
-application handling user authentication using an external service. </alt>
+the user authentication by connecting to an external directory service. The
+application can be a single-user application with an embedded
+<ph conref="../conrefs.dita#prod/productshortname"></ph> engine or a multi-user
+application server. The following figure shows this kind of deployment.</p>
+<fig expanse="column"><title>Application user authentication using an external
+service</title>
+<image href="appauth_os.gif" placement="break"><alt>This figure shows how an external directory service provides application user authentication before access to a Derby database is allowed.</alt>
</image>
</fig>
</conbody>
Modified: db/derby/docs/trunk/src/devguide/cdevcsecuree.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/devguide/cdevcsecuree.dita?rev=1090436&r1=1090435&r2=1090436&view=diff
==============================================================================
--- db/derby/docs/trunk/src/devguide/cdevcsecuree.dita (original)
+++ db/derby/docs/trunk/src/devguide/cdevcsecuree.dita Fri Apr 8 20:40:00 2011
@@ -19,7 +19,7 @@ See the License for the specific languag
limitations under the License.
-->
<concept id="cdevcsecuree" xml:lang="en-us">
-<title>Derby and Security</title>
+<title>Derby and security</title>
<shortdesc><ph conref="../conrefs.dita#prod/productshortname"></ph> can be
deployed in a number of ways and in a number of different environments. The
security needs of the <ph conref="../conrefs.dita#prod/productshortname"></ph> system
@@ -39,9 +39,8 @@ user names and passwords before permitti
to read a database or to write to a database.</p></li>
<li><i>Disk encryption</i> <p>A means of encrypting <ph conref="../conrefs.dita#prod/productshortname"></ph> data
stored on disk.</p></li>
-<li><i>Validation of Certificate for Signed Jar Files</i> <p>In a Java 2
-environment, <ph conref="../conrefs.dita#prod/productshortname"></ph> validates
-certificates for classes loaded from signed jar files.</p> </li>
+<li><i>Validation of certificates for signed jar files</i> <p><ph conref="../conrefs.dita#prod/productshortname"></ph>
+validates certificates for classes loaded from signed jar files.</p> </li>
<li><i>Network encryption and authentication</i><p><ph
conref="../conrefs.dita#prod/productshortname"></ph>
network traffic may be encrypted with SSL/TLS. SSL/TLS certificate
@@ -51,20 +50,20 @@ details.</p></li>
</ul>
<p>The following figure shows some of the <ph conref="../conrefs.dita#prod/productshortname"></ph> security
mechanisms at work in a client/server environment. User authentication is
-performed by accessing an LDAP Directory Service. The data in the database
-is not encrypted in this trusted environment.<fig expanse="column"><title>Example
-of using an LDAP Directory Service in a trusted environment.</title>
-<image href="security_os.gif" placement="break"><alt>This figure shows user
-authentication from an LDAP directory service to the Derby engine and user
-authorization to read and write data. The Derby database is a trusted environment
-and the data is not encrypted.</alt></image>
-</fig></p>
+performed by accessing an LDAP directory service. The data in the database
+is not encrypted in this trusted environment.</p>
+<fig expanse="column"><title>Using an LDAP directory service in a trusted
+environment</title>
+<image href="security_os.gif" placement="break"><alt>This figure shows user authentication from an LDAP directory service to the Derby engine, and user authorization to read and write data. The Derby database is a trusted environment, and the data is not encrypted.</alt>
+</image>
+</fig>
<p>The following figure shows how another <ph conref="../conrefs.dita#prod/productshortname"></ph> security
mechanism, disk encryption, protects data when the recipient might not know
-how to protect data. It is useful for databases deployed in an embedded environment.<fig
-expanse="column"><title>Example of using disk encryption to protect data.</title>
-<image href="security2_os.gif" placement="break"><alt>This figure shows disk
-encryption between the Derby engine and the database.</alt></image>
-</fig></p>
+how to protect data. It is useful for databases deployed in an embedded
+environment.</p>
+<fig expanse="column"><title>Using disk encryption to protect data</title>
+<image href="security2_os.gif" placement="break"><alt>This figure shows disk encryption between the Derby engine and the database.</alt>
+</image>
+</fig>
</conbody>
</concept>
Modified: db/derby/docs/trunk/src/devguide/cdevdeploy855368.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/devguide/cdevdeploy855368.dita?rev=1090436&r1=1090435&r2=1090436&view=diff
==============================================================================
--- db/derby/docs/trunk/src/devguide/cdevdeploy855368.dita (original)
+++ db/derby/docs/trunk/src/devguide/cdevdeploy855368.dita Fri Apr 8 20:40:00 2011
@@ -35,20 +35,21 @@ server. In the latter case, <ph conref="
embedded in the user-provided server framework, and any client applications
use user-provided connectivity or allow the application server to handle all
database interaction.</p>
+<p>The following figure shows
+<ph conref="../conrefs.dita#prod/productshortname"></ph> embedded in a
+single-user Java application.</p>
<fig expanse="column" id="cdevdeploy31527"><title><ph conref="../conrefs.dita#prod/productshortname"></ph> embedded
in a single-user Java application</title>
-<image href="embed_os.gif" placement="break"><alt>This figure shows the single-user
-application and the Derby database engine inside the Java Virtual Machine.
-The single-user application connects to the Derby database engine by using
-the JDBC API. The Derby database engine connects to the Derby database.</alt>
+<image href="embed_os.gif" placement="break"><alt>This figure shows the single-user application and the Derby database engine inside the Java Virtual Machine. The single-user application connects to the Derby database engine by using the JDBC API. The Derby database engine connects to the Derby database.</alt>
</image>
</fig>
-<fig expanse="column" id="cdevdeploy29107"><title>Derby embedded in a multi-user Java application
-server</title>
-<image href="itserv_os.gif" placement="break"><alt>This figure shows multiple
-users connecting to the application server, which contains the application
-and the Derby database engine. The application connects to the Derby database
-engine. The Derby database engine connects to the Derby database.</alt></image>
+<p>The following figure shows
+<ph conref="../conrefs.dita#prod/productshortname"></ph> embedded in a
+multi-user Java application server.</p>
+<fig expanse="column" id="cdevdeploy29107"><title>Derby embedded in a multi-user
+Java application server</title>
+<image href="itserv_os.gif" placement="break"><alt>This figure shows multiple users connecting to the application server, which contains the application and the Derby database engine. The application connects to the Derby database engine. The Derby database engine connects to the Derby database.</alt>
+</image>
</fig>
<p>When a <ph conref="../conrefs.dita#prod/productshortname"></ph> database
is embedded in a Java application, the database is dedicated to that single
Modified: db/derby/docs/trunk/src/devguide/cdevdeploy855655.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/devguide/cdevdeploy855655.dita?rev=1090436&r1=1090435&r2=1090436&view=diff
==============================================================================
--- db/derby/docs/trunk/src/devguide/cdevdeploy855655.dita (original)
+++ db/derby/docs/trunk/src/devguide/cdevdeploy855655.dita Fri Apr 8 20:40:00 2011
@@ -40,14 +40,10 @@ file and the database are four objects.
deployment by reducing the number of objects to two by storing the application
and the properties file in the database. </p>
<fig expanse="column" id="cdevdeploy21165"><title>Two approaches to deploying
-a Derby application in an embedded environment.</title>
-<image href="edeploy_os.gif" placement="break"><alt>This figure shows two
-graphics. The top graphic displays a slightly more complicated deployment
-of a Derby system involving four objects: the derby.jar file, your application
-jar file, the derby.properties file and the database. The bottom graphic displays
-a simplified deployment of a Derby system involving two objects. The application
-jar file and the derby properties are stored in the database. Only the derby.jar
-file is outside the database.</alt></image>
+a <ph conref="../conrefs.dita#prod/productshortname"></ph> application in an
+embedded environment</title>
+<image href="edeploy_os.gif" placement="break"><alt>This figure shows two graphics. The top graphic displays a slightly more complicated deployment of a Derby system involving four objects: the derby.jar file, your application jar file, the derby.properties file and the database. The bottom graphic displays a simplified deployment of a Derby system involving two objects. The application jar file and the derby properties are stored in the database. Only the derby.jar file is outside the database.</alt>
+</image>
</fig>
</conbody>
</concept>
Modified: db/derby/docs/trunk/src/devguide/cdevdvlp27610.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/devguide/cdevdvlp27610.dita?rev=1090436&r1=1090435&r2=1090436&view=diff
==============================================================================
--- db/derby/docs/trunk/src/devguide/cdevdvlp27610.dita (original)
+++ db/derby/docs/trunk/src/devguide/cdevdvlp27610.dita Fri Apr 8 20:40:00 2011
@@ -43,17 +43,13 @@ startup.</p>
and the system directory is an essential part of a running database or databases.
Understanding the <ph conref="../conrefs.dita#prod/productshortname"></ph> system
is essential to successful development and deployment of <ph conref="../conrefs.dita#prod/productshortname"></ph> applications.
-Derby databases live in a system, which includes system-wide properties, an
-error log, and one or more databases.</p>
-<fig expanse="column" id="rdevdvlp17155"><title>Derby databases live in a
+As the following figure shows,
+<ph conref="../conrefs.dita#prod/productshortname"></ph> databases live in a
system, which includes system-wide properties, an error log, and one or more
-databases.</title>
-<image href="system_os.gif" placement="break"><alt>This figure shows a Derby
-system that includes a database called Accounting and a database called Sales.
-The figure shows the derby.system.home system variable pointing to the databases
-and explains that this system variable tells Derby the name of your system
-directory. Additionally, this figure shows that the derby.properties file
-and the derby.log file are part of the Derby system.</alt></image>
+databases.</p>
+<fig expanse="column" id="rdevdvlp17155"><title>Derby system</title>
+<image href="system_os.gif" placement="break"><alt>This figure shows a Derby system that includes a database called Accounting and a database called Sales. The figure shows the derby.system.home system variable pointing to the databases and explains that this system variable tells Derby the name of your system directory. Additionally, this figure shows that the derby.properties file and the derby.log file are part of the Derby system.</alt>
+</image>
</fig>
<p>The system directory can also contain an error log file called <i>derby.log </i>(see <xref
href="cdevdvlp25889.dita#cdevdvlp25889"></xref>).</p>
Modified: db/derby/docs/trunk/src/devguide/cdevdvlp40724.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/devguide/cdevdvlp40724.dita?rev=1090436&r1=1090435&r2=1090436&view=diff
==============================================================================
--- db/derby/docs/trunk/src/devguide/cdevdvlp40724.dita (original)
+++ db/derby/docs/trunk/src/devguide/cdevdvlp40724.dita Fri Apr 8 20:40:00 2011
@@ -63,17 +63,15 @@ information, see <xref href="cdevdeploy1
<p>The following figure shows the files and directories in the <ph conref="../conrefs.dita#prod/productshortname"></ph> database
directories that are used by the <ph conref="../conrefs.dita#prod/productshortname"></ph> software.</p>
<fig expanse="column" id="rdevdvlp31476"><title>An example of a <ph conref="../conrefs.dita#prod/productshortname"></ph> database
-directory and file structure.</title>
-<image href="dbcont.gif" placement="break"><alt>This figure shows the files
-and directories that might be found in the main directory of a Derby database
-called Sales: the service.properties file, and the log, seg0, tmp, and jar
-directories.</alt></image>
+directory and file structure</title>
+<image href="dbcont.gif" placement="break"><alt>This figure shows the files and directories that might be found in the main directory of a Derby database called Sales: the service.properties file, and the log, seg0, tmp, and jar directories.</alt>
+</image>
</fig>
<p><ph conref="../conrefs.dita#prod/productshortname"></ph> imposes relatively
few limitations on the number and size of databases and database objects.
The following table shows some size limitations of
<ph conref="../conrefs.dita#prod/productshortname"></ph> databases
-and database objects:</p>
+and database objects.</p>
<table id="cdevdvlp85623"><title>Size limits for
<ph conref="../conrefs.dita#prod/productshortname"></ph> database objects</title>
<tgroup cols="2" colsep="1" rowsep="1"><colspec colname="1" colnum="1" colwidth="40*"/>
Modified: db/derby/docs/trunk/src/tuning/ctundepth32379.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctundepth32379.dita?rev=1090436&r1=1090435&r2=1090436&view=diff
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctundepth32379.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctundepth32379.dita Fri Apr 8 20:40:00 2011
@@ -36,17 +36,18 @@ executes statements that are almost but
which can contain dynamic or IN parameters. Instead of using the literals
for changing parameters, use question marks (?) as placeholders for such parameters.
Provide the values when you execute the statement.</p></li>
-</ul><ph conref="../conrefs.dita#prod/productshortname"></ph> supports the <i>ParameterMetaData</i> interface,
-new in JDBC 3.0. This interface describes the number, type, and properties
+</ul></p>
+<p><ph conref="../conrefs.dita#prod/productshortname"></ph> supports the
+<i>ParameterMetaData</i> interface. This interface describes the number, type, and properties
of prepared statement parameters. See the <cite><ph conref="../conrefs.dita#pub/citdevelop"></ph></cite> for
more information.</p>
-<p> <fig expanse="column" id="ctundepth42475"><title>A connection need only
-compile a <i>PreparedStatement</i> once</title><desc>Subsequent executions
-can use the same statement execution plan even if the parameter values are
-different. (<i>PreparedStatements</i> are not shared across connections.)</desc>
-<image href="pstmt_os.gif" placement="break"><alt>This figure shows one connection
-with multiple executions of the same PreparedStatement, which uses the same
-statement execution plan.</alt></image>
+<p>A connection need only compile a <i>PreparedStatement</i> once. Subsequent
+executions can use the same statement execution plan even if the parameter
+values are different, as shown in the following figure.
+(<i>PreparedStatements</i> are not shared across connections.)</p>
+<fig expanse="column" id="ctundepth42475"><title>Prepared statements and the
+statement cache</title>
+<image href="pstmt_os.gif" placement="break"><alt>This figure shows multiple executions of the same PreparedStatement over a single connection. The single PreparedStatement object uses the same statement execution plan and statement cache.</alt></image>
</fig><ul>
<li>Even if your statement uses <i>Statements</i> instead of <i>PreparedStatements</i>, <ph
conref="../conrefs.dita#prod/productshortname"></ph> can reuse the statement
@@ -65,17 +66,19 @@ meet the following requirements:</p> <ul
<li>The Unicode flag that the statement was compiled under must match the
current connection's flag</li>
</ul></li>
-</ul></p>
+</ul>
<note type="remember">If your application executes statements that are almost
but not exactly alike, it is more efficient to use <i>PreparedStatements</i> with
dynamic or IN parameters. </note>
-<fig expanse="column" id="ctundepth12523"><title>A database can reuse a statement
-execution plan when the SQL text matches a prior statement <i>exactly</i></title>
-<desc>(<i>PreparedStatements</i> are much more efficient.)</desc>
-<image href="stmt_os.gif" placement="break"><alt>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.</alt>
-</image>
+<p>The following figure shows how
+<ph conref="../conrefs.dita#prod/productshortname"></ph> can reuse a statement
+execution plan that is already in the statement cache when the SQL text matches
+a prior statement <i>exactly</i>, even when the statement is executed from a
+different connection. <i>PreparedStatements</i> are much more efficient,
+however.</p>
+<fig expanse="column" id="ctundepth12523"><title>Statements and the statement
+cache</title>
+<image href="stmt_os.gif" placement="break"><alt>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. The figure shows three executions of two similar statements over two different database connections. Each database connection has its own statement cache. One statement is "SELECT * FROM mytable WHERE id = ?". The other statement is "SELECT * FROM mytable WHERE id = 2". The statement that uses the dynamic parameter is executed on both Connection One and Connection Two. When it is executed the second time, on Connection Two, it can use the statement execution plan that is already in the statement cache of Connection One. The version that does not use a dynamic parameter is executed on Connection Two only and uses the statement cache for Connection Two.</alt></image>
</fig>
</conbody>
</concept>