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 sc...@apache.org on 2007/02/15 21:37:46 UTC
svn commit: r508132 - in /db/derby/docs/trunk/src: devguide/ tuning/
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>
-