db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From chaa...@apache.org
Subject svn commit: r1090455 - in /db/derby/docs/branches/10.8/src: devguide/ tuning/
Date Fri, 08 Apr 2011 21:33:08 GMT
Author: chaase3
Date: Fri Apr  8 21:33:08 2011
New Revision: 1090455

URL: http://svn.apache.org/viewvc?rev=1090455&view=rev
Log:
DERBY-5171 Fix uses of <alt> and <desc> elements and figure captions

Merged DERBY-5171.diff to 10.8 docs branch from trunk revision 1090436.

Modified:
    db/derby/docs/branches/10.8/src/devguide/cdevconcepts16400.dita
    db/derby/docs/branches/10.8/src/devguide/cdevconcepts28436.dita
    db/derby/docs/branches/10.8/src/devguide/cdevcsecure42374.dita
    db/derby/docs/branches/10.8/src/devguide/cdevcsecuree.dita
    db/derby/docs/branches/10.8/src/devguide/cdevdeploy855368.dita
    db/derby/docs/branches/10.8/src/devguide/cdevdeploy855655.dita
    db/derby/docs/branches/10.8/src/devguide/cdevdvlp27610.dita
    db/derby/docs/branches/10.8/src/devguide/cdevdvlp40724.dita
    db/derby/docs/branches/10.8/src/tuning/ctundepth32379.dita

Modified: db/derby/docs/branches/10.8/src/devguide/cdevconcepts16400.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/branches/10.8/src/devguide/cdevconcepts16400.dita?rev=1090455&r1=1090454&r2=1090455&view=diff
==============================================================================
--- db/derby/docs/branches/10.8/src/devguide/cdevconcepts16400.dita (original)
+++ db/derby/docs/branches/10.8/src/devguide/cdevconcepts16400.dita Fri Apr  8 21:33:08 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/branches/10.8/src/devguide/cdevconcepts28436.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/branches/10.8/src/devguide/cdevconcepts28436.dita?rev=1090455&r1=1090454&r2=1090455&view=diff
==============================================================================
--- db/derby/docs/branches/10.8/src/devguide/cdevconcepts28436.dita (original)
+++ db/derby/docs/branches/10.8/src/devguide/cdevconcepts28436.dita Fri Apr  8 21:33:08 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/branches/10.8/src/devguide/cdevcsecure42374.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/branches/10.8/src/devguide/cdevcsecure42374.dita?rev=1090455&r1=1090454&r2=1090455&view=diff
==============================================================================
--- db/derby/docs/branches/10.8/src/devguide/cdevcsecure42374.dita (original)
+++ db/derby/docs/branches/10.8/src/devguide/cdevcsecure42374.dita Fri Apr  8 21:33:08 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/branches/10.8/src/devguide/cdevcsecuree.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/branches/10.8/src/devguide/cdevcsecuree.dita?rev=1090455&r1=1090454&r2=1090455&view=diff
==============================================================================
--- db/derby/docs/branches/10.8/src/devguide/cdevcsecuree.dita (original)
+++ db/derby/docs/branches/10.8/src/devguide/cdevcsecuree.dita Fri Apr  8 21:33:08 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/branches/10.8/src/devguide/cdevdeploy855368.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/branches/10.8/src/devguide/cdevdeploy855368.dita?rev=1090455&r1=1090454&r2=1090455&view=diff
==============================================================================
--- db/derby/docs/branches/10.8/src/devguide/cdevdeploy855368.dita (original)
+++ db/derby/docs/branches/10.8/src/devguide/cdevdeploy855368.dita Fri Apr  8 21:33:08 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/branches/10.8/src/devguide/cdevdeploy855655.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/branches/10.8/src/devguide/cdevdeploy855655.dita?rev=1090455&r1=1090454&r2=1090455&view=diff
==============================================================================
--- db/derby/docs/branches/10.8/src/devguide/cdevdeploy855655.dita (original)
+++ db/derby/docs/branches/10.8/src/devguide/cdevdeploy855655.dita Fri Apr  8 21:33:08 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/branches/10.8/src/devguide/cdevdvlp27610.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/branches/10.8/src/devguide/cdevdvlp27610.dita?rev=1090455&r1=1090454&r2=1090455&view=diff
==============================================================================
--- db/derby/docs/branches/10.8/src/devguide/cdevdvlp27610.dita (original)
+++ db/derby/docs/branches/10.8/src/devguide/cdevdvlp27610.dita Fri Apr  8 21:33:08 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/branches/10.8/src/devguide/cdevdvlp40724.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/branches/10.8/src/devguide/cdevdvlp40724.dita?rev=1090455&r1=1090454&r2=1090455&view=diff
==============================================================================
--- db/derby/docs/branches/10.8/src/devguide/cdevdvlp40724.dita (original)
+++ db/derby/docs/branches/10.8/src/devguide/cdevdvlp40724.dita Fri Apr  8 21:33:08 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/branches/10.8/src/tuning/ctundepth32379.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/branches/10.8/src/tuning/ctundepth32379.dita?rev=1090455&r1=1090454&r2=1090455&view=diff
==============================================================================
--- db/derby/docs/branches/10.8/src/tuning/ctundepth32379.dita (original)
+++ db/derby/docs/branches/10.8/src/tuning/ctundepth32379.dita Fri Apr  8 21:33:08 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>



Mime
View raw message