db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From scotsmat...@apache.org
Subject svn commit: r508132 - in /db/derby/docs/trunk/src: devguide/ tuning/
Date Thu, 15 Feb 2007 20:37:46 GMT
Author: scotsmatrix
Date: Thu Feb 15 12:37:45 2007
New Revision: 508132

URL: http://svn.apache.org/viewvc?view=rev&rev=508132
Log:
Derby-1842: Added or corrected the ALT text for all of the graphic files in the dev and tuning
guides. Patch submitted by me.

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?view=diff&rev=508132&r1=508131&r2=508132
==============================================================================
--- db/derby/docs/trunk/src/devguide/cdevconcepts16400.dita (original)
+++ db/derby/docs/trunk/src/devguide/cdevconcepts16400.dita Thu Feb 15 12:37:45 2007
@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="utf-8"?>
-
+ 
 <!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN"
  "../dtd/concept.dtd">
 <!-- 
@@ -23,7 +23,11 @@
 <shortdesc>You configure the amount of time a transaction waits before <ph
 conref="devconrefs.dita#prod/productshortname"></ph> does any deadlock checking
 with the <i>derby.locks.deadlockTimeout</i> property.</shortdesc>
-<prolog></prolog>
+<prolog><metadata>
+<keywords><indexterm>deadlocks<indexterm>configuring detection</indexterm></indexterm>
+<indexterm>deadlocks<indexterm>configuring lock wait timeouts</indexterm></indexterm>
+</keywords>
+</metadata></prolog>
 <conbody>
 <p>You configure the amount of time a transaction waits before timing out
 with the <codeph><i>derby.locks.waitTimeout</i></codeph> property.
When configuring
@@ -40,24 +44,24 @@
 <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 illustration depicts
-one possible configuration: deadlock checking occurs when a transaction has
-waited 30 seconds; no lock wait timeouts occur.</alt></image>
+<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>
 </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 illustration depicts
-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.</alt></image>
+<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>
+</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 illustration depicts
-a configuration in which no deadlock checking occurs: transactions time out
-after they have waited 50 seconds. No deadlock checking occurs.</alt></image>
+<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>
 </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?view=diff&rev=508132&r1=508131&r2=508132
==============================================================================
--- db/derby/docs/trunk/src/devguide/cdevconcepts28436.dita (original)
+++ db/derby/docs/trunk/src/devguide/cdevconcepts28436.dita Thu Feb 15 12:37:45 2007
@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="utf-8"?>
-
+ 
 <!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN"
  "../dtd/concept.dtd">
 <!-- 
@@ -23,7 +23,7 @@
 <shortdesc>In a database, a deadlock is a situation in which two or more transactions
 are waiting for one another to give up locks.</shortdesc>
 <prolog><metadata>
-<keywords><indexterm>Deadlocks<indexterm>description</indexterm></indexterm>
+<keywords><indexterm>deadlocks<indexterm>description</indexterm></indexterm>
 </keywords>
 </metadata></prolog>
 <conbody>
@@ -35,10 +35,12 @@
 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>
-<fig expanse="column"><title>A deadlock.</title>
-<image href="dead.gif" placement="break"><alt>This figure depicts a deadlock,
-where two transactions are waiting for one another to give up locks.</alt>
-</image>
+<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>
 </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?view=diff&rev=508132&r1=508131&r2=508132
==============================================================================
--- db/derby/docs/trunk/src/devguide/cdevcsecure42374.dita (original)
+++ db/derby/docs/trunk/src/devguide/cdevcsecure42374.dita Thu Feb 15 12:37:45 2007
@@ -50,27 +50,28 @@
 <p>When <ph conref="devconrefs.dita#prod/productshortname"></ph> user authentication
 is enabled and <ph conref="devconrefs.dita#prod/productshortname"></ph> uses
 an external directory service, the architecture looks something like that
-shown in the Figure below: </p>
+shown in the figure below. </p>
 <fig expanse="column" id="cdevcsecure32704"><title><ph conref="devconrefs.dita#prod/productshortname"></ph>
user
 authentication using an external service. The application can be a single-user
 application with an embedded <ph conref="devconrefs.dita#prod/productshortname"></ph>
engine
 or a multi-user application server.</title>
-<image href="authentic_os.gif" placement="break"><alt>Derby user authentication
-using an external service.</alt></image>
+<image href="authentic_os.gif" placement="break"><alt>This figure shows Derby
+handling user authentication using an external service. </alt></image>
 </fig>
 <p><ph conref="devconrefs.dita#prod/productshortname"></ph> always runs
embedded
 in another Java application, whether that application is a single-user application
-or a multiple-user application server or connectivity framework. 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="devconrefs.dita#prod/productshortname"></ph>
is
+or a multiple-user application server or connectivity framework. </p>
+<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="devconrefs.dita#prod/productshortname"></ph>
is
 embedded, not <ph conref="devconrefs.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="devconrefs.dita#prod/productshortname"></ph> engine
 or a multi-user application server.</title>
-<image href="appauth_os.gif" placement="break"><alt>The application user authentication
-as an external service.</alt></image>
+<image href="appauth_os.gif" placement="break"><alt>This figure shows the
+application handling user authentication using an external service. </alt>
+</image>
 </fig>
 </conbody>
 </concept>

Modified: db/derby/docs/trunk/src/devguide/cdevcsecuree.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/devguide/cdevcsecuree.dita?view=diff&rev=508132&r1=508131&r2=508132
==============================================================================
--- db/derby/docs/trunk/src/devguide/cdevcsecuree.dita (original)
+++ db/derby/docs/trunk/src/devguide/cdevcsecuree.dita Thu Feb 15 12:37:45 2007
@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="utf-8"?>
-
+ 
 <!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN"
  "../dtd/concept.dtd">
 <!-- 
@@ -25,9 +25,9 @@
 security needs of the <ph conref="devconrefs.dita#prod/productshortname"></ph>
system
 are also diverse.</shortdesc>
 <prolog><metadata>
-<keywords><indexterm>User authentication<indexterm>definition</indexterm></indexterm>
-<indexterm>Authentication<indexterm>definition</indexterm></indexterm><indexterm>Disk
-encryption</indexterm><indexterm>Encrypting databases</indexterm></keywords>
+<keywords><indexterm>user authentication<indexterm>definition</indexterm></indexterm>
+<indexterm>authentication<indexterm>definition</indexterm></indexterm><indexterm>disk
+encryption</indexterm><indexterm>encrypting databases</indexterm></keywords>
 </metadata></prolog>
 <conbody>
 <p><ph conref="devconrefs.dita#prod/productshortname"></ph> supplies or
supports
@@ -41,17 +41,24 @@
 stored on disk.</p></li>
 <li><i>Validation of Certificate for Signed Jar Files</i>   <p>In
a Java 2
 environment, <ph conref="devconrefs.dita#prod/productshortname"></ph> validates
-certificates for classes loaded from signed jar files.</p>  <fig expanse="column">
-<title>Some of the <ph conref="devconrefs.dita#prod/productshortname"></ph>
security
-mechanisms at work in a client/server environment</title>
-<image href="security_os.gif" placement="break"><alt>Some of the Derby security
-mechanisms at work in a client/server environment.</alt></image>
-</fig> <fig expanse="column"><title>Another <ph conref="devconrefs.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.</title>
-<image href="security2_os.gif" placement="break"><alt>The disk encryption
-security mechanism.</alt></image>
-</fig></li>
+certificates for classes loaded from signed jar files.</p>  </li>
 </ul>
+<p>The following figure shows some of the <ph conref="devconrefs.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>
+<p>The following figure shows how another <ph conref="devconrefs.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>
 </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?view=diff&rev=508132&r1=508131&r2=508132
==============================================================================
--- db/derby/docs/trunk/src/devguide/cdevdeploy855368.dita (original)
+++ db/derby/docs/trunk/src/devguide/cdevdeploy855368.dita Thu Feb 15 12:37:45 2007
@@ -1,4 +1,5 @@
 <?xml version="1.0" encoding="utf-8"?>
+ 
 <!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN"
  "../dtd/concept.dtd">
 <!-- 
@@ -22,11 +23,11 @@
 <shortdesc>In an embedded environment, <ph conref="devconrefs.dita#prod/productshortname"></ph>
runs
 in the same JVM as the application.</shortdesc>
 <prolog><metadata>
-<keywords><indexterm>Embedded environments</indexterm><indexterm>Embedded
-applications<indexterm>deploying</indexterm></indexterm><indexterm>Embedded
-environments<indexterm>Derby as single-user database</indexterm></indexterm>
-<indexterm>Embedded environments<indexterm>how applications interact with
-Derby in</indexterm></indexterm></keywords>
+<keywords><indexterm>embedded applications<indexterm>deploying</indexterm></indexterm>
+<indexterm>embedded environments<indexterm>single-user application</indexterm></indexterm>
+<indexterm>embedded environments<indexterm>multi-user application server</indexterm></indexterm>
+<indexterm>embedded environments<indexterm>overview</indexterm></indexterm>
+</keywords>
 </metadata></prolog>
 <conbody>
 <p>The application can be a single-user application or a multi-user application
@@ -36,13 +37,18 @@
 database interaction.</p>
 <fig id="cdevdeploy31527"><title><ph conref="devconrefs.dita#prod/productshortname"></ph>
embedded
 in a single-user Java application</title>
-<image href="embed_os.gif" placement="break"><alt>Derby in a single-user application
-scenario.</alt></image>
+<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 id="cdevdeploy29107"><title>Derby embedded in a multi-user Java application
 server</title>
-<image href="itserv_os.gif" placement="break"><alt>Derby in a multi-user application
-scenario.</alt></image>
+<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="devconrefs.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?view=diff&rev=508132&r1=508131&r2=508132
==============================================================================
--- db/derby/docs/trunk/src/devguide/cdevdeploy855655.dita (original)
+++ db/derby/docs/trunk/src/devguide/cdevdeploy855655.dita Thu Feb 15 12:37:45 2007
@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="utf-8"?>
-
+ 
 <!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN"
  "../dtd/concept.dtd">
 <!-- 
@@ -20,28 +20,34 @@
 -->
 <concept id="cdevdeploy855655" xml:lang="en-us">
 <title>Deploying Derby in an embedded environment</title>
-<shortdesc>You can "embed" <ph conref="devconrefs.dita#prod/productshortname"></ph>
in
+<shortdesc>You can embed <ph conref="devconrefs.dita#prod/productshortname"></ph>
in
 any Java application (single- or multi-user) by deploying the following packages.</shortdesc>
 <prolog><metadata>
-<keywords><indexterm>derby.jar</indexterm><indexterm>Embedded environments</indexterm>
-<indexterm>Embedded environments<indexterm>how to deploy Derby</indexterm></indexterm>
-</keywords>
+<keywords><indexterm>derby.jar</indexterm><indexterm>embedded environments<indexterm>deployment
+configurations</indexterm></indexterm></keywords>
 </metadata></prolog>
 <conbody>
 <ul>
 <li>The <ph conref="devconrefs.dita#prod/productshortname"></ph> library
(<i>derby.jar</i>).</li>
-<li>The application's libraries. You have the option of storing these libraries
-in the database.</li>
+<li>The libraries for the application. You have the option of storing these
+libraries in the database.</li>
 <li>The database or databases used by the application, in the context of their
-system directory.<fig expanse="column" id="cdevdeploy21165"><title>Deploying
-an application, embedded Derby software, and the database. Storing the application
-in the database and setting properties as database-wide properties simplify
-deployment.</title>
-<image href="edeploy_os.gif" placement="break"><alt>Graphic 1; A slightly
-more complicated deployment with the application and properties outside of
-the database. Graphic 2; A simplified deployment with application and properties
-stored in the database.</alt></image>
-</fig></li>
+system directory.</li>
 </ul>
+<p>In the following figure, the top graphic shows the deployment of an application,
+where the application, the Derby software for embedded use, the derby.properties
+file and the database are four objects. The bottom graphic shows a simplified
+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>
+</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?view=diff&rev=508132&r1=508131&r2=508132
==============================================================================
--- db/derby/docs/trunk/src/devguide/cdevdvlp27610.dita (original)
+++ db/derby/docs/trunk/src/devguide/cdevdvlp27610.dita Thu Feb 15 12:37:45 2007
@@ -39,15 +39,21 @@
 <p>The <ph conref="devconrefs.dita#prod/productshortname"></ph> system
is
 not persistent; you must specify the location of the system directory at every
 startup.</p>
-<p>However, the system - as well as its directory, which you name - is an
-essential part of a running database or databases. Understanding the <ph conref="devconrefs.dita#prod/productshortname"></ph>
system
-is essential to successful development and deployment of <ph conref="devconrefs.dita#prod/productshortname"></ph>
applications.</p>
+<p>However, the <ph conref="devconrefs.dita#prod/productshortname"></ph>
system
+and the system directory is an essential part of a running database or databases.
+Understanding the <ph conref="devconrefs.dita#prod/productshortname"></ph> system
+is essential to successful development and deployment of <ph conref="devconrefs.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
 system, which includes system-wide properties, an error log, and one or more
 databases.</title>
-<image href="system_os.gif" placement="break"><alt>Derby databases live in
-a system, which includes system-wide properties, an error log, and one or
-more databases.</alt></image>
+<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?view=diff&rev=508132&r1=508131&r2=508132
==============================================================================
--- db/derby/docs/trunk/src/devguide/cdevdvlp40724.dita (original)
+++ db/derby/docs/trunk/src/devguide/cdevdvlp40724.dita Thu Feb 15 12:37:45 2007
@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="utf-8"?>
-
+ 
 <!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN"
  "../dtd/concept.dtd">
 <!-- 
@@ -24,19 +24,18 @@
 is stored in files that live in a directory of the same name as the database.
 Database directories typically live in <i>system</i> directories.</shortdesc>
 <prolog><metadata>
-<keywords><indexterm>log directory<indexterm>function</indexterm></indexterm>
-<indexterm>seg0 directory</indexterm><indexterm>service.properties file</indexterm>
-<indexterm>tmp directory<indexterm>function</indexterm></indexterm><indexterm>jar
-directory<indexterm>function</indexterm></indexterm><indexterm>Size
limitations
-of Derby objects and databases</indexterm><indexterm>Tables<indexterm>maximum
-number allowed per database</indexterm><indexterm>size limitations</indexterm></indexterm>
-<indexterm>Indexes<indexterm>maximum number allowed per table</indexterm></indexterm>
-<indexterm>Columns<indexterm>maximum number allowed per table</indexterm></indexterm>
-<indexterm>Rows<indexterm>maximum number allowed per table</indexterm><indexterm>size
-limitations</indexterm></indexterm></keywords>
+<keywords><indexterm>log directory<indexterm>description</indexterm></indexterm>
+<indexterm>seg0 directory</indexterm><indexterm>service.properties file<indexterm>description</indexterm></indexterm>
+<indexterm>tmp directory<indexterm>description</indexterm></indexterm><indexterm>jar
+directory<indexterm>description</indexterm></indexterm><indexterm>size
limitations
+in Derby</indexterm><indexterm>tables<indexterm>database size limitations</indexterm></indexterm>
+<indexterm>indexes<indexterm>table size limitations</indexterm></indexterm>
+<indexterm>columns<indexterm>table size limitations</indexterm></indexterm>
+<indexterm>rows<indexterm>table size limitations</indexterm></indexterm></keywords>
 </metadata></prolog>
 <conbody>
-<p>A database directory contains the following, as shown in <xref href="cdevdvlp40724.dita#cdevdvlp40724/rdevdvlp31476"></xref>:</p>
+<p>A database directory contains the following, as shown in the following
+figure.</p>
 <ul>
 <li><i>log</i> directory <p>Contains files that make up the database
transaction
 log, used internally for data recovery (not the same thing as the error log).</p></li>
@@ -50,23 +49,27 @@
 For databases on read-only media, you might need to set a property to change
 the location of this directory. See "Creating <ph conref="devconrefs.dita#prod/productshortname"></ph>
Databases
 for Read-Only Use".</p></li>
-<li><i>jar</i> directory  <p>(might not  exist.) A directory in which
jar
-files are stored when you use database class loading.</p></li>
+<li><i>jar</i> directory  <p>(might not exist.) A directory in which
jar files
+are stored when you use database class loading.</p></li>
 </ul>
 <p id="cdevdvlpaccessingareadonlydatabaseinazip">Read-only database directories
 can be archived (and compressed, if desired) into jar or zip files. For more
 information, see <xref href="cdevdeploy11201.dita#cdevdeploy11201"></xref>.</p>
-<fig expanse="column" id="rdevdvlp31476"><title><ph conref="devconrefs.dita#prod/productshortname"></ph>
database
-directories contain files and directories used by the software.</title>
-<image href="dbcont.gif" placement="break"><alt>A Derby database directory
-containing files and directories.</alt></image>
+<p>The following figure shows the files and directories in the <ph conref="devconrefs.dita#prod/productshortname"></ph>
database
+directories that are used by the <ph conref="devconrefs.dita#prod/productshortname"></ph>
software.</p>
+<fig expanse="column" id="rdevdvlp31476"><title>An example of a <ph conref="devconrefs.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>
 </fig>
 <p><ph conref="devconrefs.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="devconrefs.dita#prod/productshortname"></ph>
databases
 and database objects:</p>
-<table id="cdevdvlp85623" rowheader="firstcol"><title>Size Limits to Derby
-Database Objects</title>
+<table id="cdevdvlp85623" rowheader="firstcol"><title>Size limits for Derby
+database objects</title>
 <tgroup cols="2" colsep="1" rowsep="1"><colspec colname="1" colnum="1" colwidth="40*"/>
 <colspec colname="2" colnum="2" colwidth="60*"/>
 <thead>
@@ -77,16 +80,16 @@
 </thead>
 <tbody>
 <row>
-<entry colname="1">tables per database</entry>
+<entry colname="1">tables in each database</entry>
 <entry colname="2"><i>java.lang.Long.MAX_VALUE</i>   <p>Some operating
systems
 impose a limit to the number of files allowed in a single directory.</p></entry>
 </row>
 <row>
-<entry colname="1">indexes per table</entry>
+<entry colname="1">indexes in each table</entry>
 <entry colname="2">32,767 or storage</entry>
 </row>
 <row>
-<entry colname="1">columns per table</entry>
+<entry colname="1">columns in each table</entry>
 <entry colname="2">1,012</entry>
 </row>
 <row>
@@ -94,19 +97,19 @@
 <entry colname="2">16</entry>
 </row>
 <row>
-<entry colname="1">rows per table</entry>
-<entry colname="2">no limit</entry>
+<entry colname="1">rows in each table</entry>
+<entry colname="2">No limit.</entry>
 </row>
 <row>
 <entry colname="1">size of table</entry>
-<entry colname="2">no limit Some operating systems impose a limit on the size
-of a single file.</entry>
+<entry colname="2">No limit. Some operating systems impose a limit on the
+size of a single file.</entry>
 </row>
 <row>
 <entry colname="1">size of row</entry>
-<entry colname="2">no limit--rows can span pages. Rows cannot span tables
-so some operating systems impose a limit on the size of a single file, and
-therefore limit the size of a table and size of a row in that table.</entry>
+<entry colname="2">No limit. Rows can span pages. Rows cannot span tables
+so some operating systems impose a limit on the size of a single file, which
+results in limiting the size of a table and size of a row in that table.</entry>
 </row>
 </tbody>
 </tgroup>

Modified: db/derby/docs/trunk/src/tuning/ctundepth32379.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/tuning/ctundepth32379.dita?view=diff&rev=508132&r1=508131&r2=508132
==============================================================================
--- db/derby/docs/trunk/src/tuning/ctundepth32379.dita (original)
+++ db/derby/docs/trunk/src/tuning/ctundepth32379.dita Thu Feb 15 12:37:45 2007
@@ -1,4 +1,7 @@
 <?xml version="1.0" encoding="utf-8"?>
+ 
+<!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN"
+ "../dtd/concept.dtd">
 <!-- 
 Licensed to the Apache Software Foundation (ASF) under one or more
 contributor license agreements.  See the NOTICE file distributed with
@@ -15,9 +18,6 @@
 See the License for the specific language governing permissions and  
 limitations under the License.
 -->
-
-<!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN"
- "../dtd/concept.dtd">
 <concept id="ctundepth32379" xml:lang="en-us">
 <title>Using the statement cache</title>
 <prolog><metadata>
@@ -31,12 +31,11 @@
 compilation overhead:   <ul>
 <li>Your application can use <i>PreparedStatements</i> instead of <i>Statements</i>.
   <p><i>PreparedStatements</i> are JDBC objects that you prepare (compile)
-once and execute multiple times. (See <xref href="ctundepth32379.dita#ctundepth32379/ctundepth42475"
-type="fig"></xref>.) If your application executes statements
-that are almost but not exactly alike, use <i>PreparedStatements</i>, 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>
+once and execute multiple times. See the figure below. If your application
+executes statements that are almost but not exactly alike, use <i>PreparedStatements</i>,
+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="tunconrefs.dita#prod/productshortname"></ph> supports
the <i>ParameterMetaData</i> interface,
 new in JDBC 3.0. This interface describes the number, type, and properties
 of prepared statement parameters. See the <cite><ph conref="tunconrefs.dita#pub/citdevelop"></ph></cite>
for
@@ -45,38 +44,38 @@
 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>Multiple executions of the
-same PreparedStatement and their relationship to the statement execution plan.</alt>
-</image>
-</fig> <ul>
+<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>
+</fig><ul>
 <li>Even if your statement uses <i>Statements</i> instead of <i>PreparedStatements</i>,
<ph
 conref="tunconrefs.dita#prod/productshortname"></ph> can reuse the statement
 execution plan for the statements from the statement cache. Statements from
 any connection can share the same statement execution plan, avoiding compilation,
 by using the single-statement cache. The statement cache maintains statement
 plans across connections. It does not, however, maintain them across reboots.
-(See <xref href="ctundepth32379.dita#ctundepth32379/ctundepth12523"></xref>.)
  <p>When, in the
-same database, an application submits an SQL <i>Statement</i> that exactly
-matches one already in the cache, <ph conref="tunconrefs.dita#prod/productshortname"></ph>
grabs
-the statement from the cache, even if the <i>Statement</i> has already been
-closed by the application.</p> <p>To match exactly with a statement already
-in the cache, the SQL <i>Statement</i> must meet the following requirements:</p>
<ul>
+See the figure below. <p>When, in the same database, an application submits
+an SQL <i>Statement</i> that exactly matches one already in the cache, <ph
+conref="tunconrefs.dita#prod/productshortname"></ph> grabs the statement from
+the cache, even if the <i>Statement</i> has already been closed by the application.</p>
<p>To
+match exactly with a statement already in the cache, the SQL <i>Statement</i>
must
+meet the following requirements:</p> <ul>
 <li>The text must match exactly</li>
 <li>The current schema must match</li>
-<li>The unicode flag that the statement was compiled under must match the
+<li>The Unicode flag that the statement was compiled under must match the
 current connection's flag</li>
 </ul></li>
 </ul></p>
-<note>Remember that if your application executes statements that are almost
+<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="page" 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 align="center" href="stmt_os.gif" placement="break"><alt>The database
-reusing a statement execution plan that is already in the statement cache.</alt>
+<image align="center" 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>
 </fig>
 </conbody>
 </concept>
-



Mime
View raw message