Return-Path:
Delivered-To: apmail-db-derby-commits-archive@www.apache.org
Received: (qmail 55314 invoked from network); 8 Apr 2011 21:33:31 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3)
by minotaur.apache.org with SMTP; 8 Apr 2011 21:33:31 -0000
Received: (qmail 46331 invoked by uid 500); 8 Apr 2011 21:33:31 -0000
Delivered-To: apmail-db-derby-commits-archive@db.apache.org
Received: (qmail 46312 invoked by uid 500); 8 Apr 2011 21:33:31 -0000
Mailing-List: contact derby-commits-help@db.apache.org; run by ezmlm
Precedence: bulk
list-help:
list-unsubscribe:
List-Post:
Reply-To: "Derby Development"
List-Id:
Delivered-To: mailing list derby-commits@db.apache.org
Received: (qmail 46305 invoked by uid 99); 8 Apr 2011 21:33:31 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 08 Apr 2011 21:33:31 +0000
X-ASF-Spam-Status: No, hits=-2000.0 required=5.0
tests=ALL_TRUSTED
X-Spam-Check-By: apache.org
Received: from [140.211.11.4] (HELO eris.apache.org) (140.211.11.4)
by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 08 Apr 2011 21:33:29 +0000
Received: by eris.apache.org (Postfix, from userid 65534)
id 1F57223889E1; Fri, 8 Apr 2011 21:33:09 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: svn commit: r1090455 - in /db/derby/docs/branches/10.8/src: devguide/
tuning/
Date: Fri, 08 Apr 2011 21:33:08 -0000
To: derby-commits@db.apache.org
From: chaase3@apache.org
X-Mailer: svnmailer-1.0.8
Message-Id: <20110408213309.1F57223889E1@eris.apache.org>
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 and 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.
set to 60 seconds. -1 is the equivalent of no wait timeout. This means that
transactions never time out, although can
choose a transaction as a deadlock victim.
-One possible configuration:
-deadlock checking occurs when a transaction has waited 30 seconds; no lock
-wait timeouts occur.
-This figure shows a configuration
-where deadlock checking occurs when a transaction has waited 30 seconds. No
-lock wait timeouts occur.
+In the following figure, derby.locks.deadlockTimeout
+is set to 30 seconds, while derby.locks.waitTimeout has
+no limit.
+Configuration with
+deadlock checking after 30 seconds and no lock wait timeouts
+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).
+
-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.
-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.
+In the following figure, derby.locks.deadlockTimeout
+is set to 60 seconds, while derby.locks.waitTimeout is
+set to 90 seconds.
+Configuration with
+deadlock checking after 60 seconds and lock wait timeout at 90 seconds
+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.
-A configuration in which
-no deadlock checking occurs: transactions time out after they have waited
-50 seconds. No deadlock checking occurs.
-This figure shows a configuration
-where no deadlock checking occurs. The transactions time out after they have
-waited 50 seconds. No deadlock checking occurs.
+In the following figure, derby.locks.deadlockTimeout
+is set to 60 seconds, while derby.locks.waitTimeout is
+set to 50 seconds, lower than the deadlock timeout limit.
+Configuration with
+no deadlock checking and a 50-second lock wait timeout
+This figure shows a configuration where no deadlock checking occurs. The transactions time out after they have waited 50 seconds.
+
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 Accounts table he
cannot complete its transaction because of the lock on Orders. Transaction
B cannot complete its transaction because of the lock on Accounts.
All activity comes to a halt and remains at a standstill forever unless the
-DBMS detects the deadlock and aborts one of the transactions.
+DBMS detects the deadlock and aborts one of the transactions. The following
+figure shows this situation.
A deadlock where two transactions are waiting
-for one another to give up locks.
-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.
+for one another to give up locks
+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.
+
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
When user authentication
is enabled and uses
an external directory service, the architecture looks something like that
-shown in the figure below.
- user
-authentication using an external service. The application can be a single-user
-application with an embedded engine
-or a multi-user application server.
-This figure shows Derby
-handling user authentication using an external service.
+shown in the following figure. The application can be a single-user application with
+an embedded engine
+or a multi-user application server.
+
+user authentication using an external service
+This figure shows how an application passes Derby user authentication through an external directory service before access to a Derby database is allowed.
+
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
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 is
embedded, not , handles
-the user authentication by connecting to an external directory service.
-The application provides the user authentication
-using an external service. The application can be a single-user application
-with an embedded engine
-or a multi-user application server.
-This figure shows the
-application handling user authentication using an external service.
+the user authentication by connecting to an external directory service. The
+application can be a single-user application with an embedded
+ engine or a multi-user
+application server. The following figure shows this kind of deployment.
+Application user authentication using an external
+service
+This figure shows how an external directory service provides application user authentication before access to a Derby database is allowed.
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.
-->
-Derby and Security
+Derby and security
can be
deployed in a number of ways and in a number of different environments. The
security needs of the system
@@ -39,9 +39,8 @@ user names and passwords before permitti
to read a database or to write to a database.
Disk encryption A means of encrypting data
stored on disk.
-Validation of Certificate for Signed Jar Files In a Java 2
-environment, validates
-certificates for classes loaded from signed jar files.
+Validation of certificates for signed jar files
+validates certificates for classes loaded from signed jar files.
Network encryption and authentication
network traffic may be encrypted with SSL/TLS. SSL/TLS certificate
@@ -51,20 +50,20 @@ details.
The following figure shows some of the 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.Example
-of using an LDAP Directory Service in a trusted environment.
-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.
-
+performed by accessing an LDAP directory service. The data in the database
+is not encrypted in this trusted environment.
+Using an LDAP directory service in a trusted
+environment
+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.
+
+
The following figure shows how another 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.Example of using disk encryption to protect data.
-This figure shows disk
-encryption between the Derby engine and the database.
-
+how to protect data. It is useful for databases deployed in an embedded
+environment.
+Using disk encryption to protect data
+This figure shows disk encryption between the Derby engine and the database.
+
+
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, embedded in a
+single-user Java application.
embedded
in a single-user Java application
-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.
+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.
-Derby embedded in a multi-user Java application
-server
-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.
+The following figure shows
+ embedded in a
+multi-user Java application server.
+Derby embedded in a multi-user
+Java application server
+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.
+
When a 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.
Two approaches to deploying
-a Derby application in an embedded environment.
-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.
+a application in an
+embedded environment
+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.
+
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.
and the system directory is an essential part of a running database or databases.
Understanding the system
is essential to successful development and deployment of applications.
-Derby databases live in a system, which includes system-wide properties, an
-error log, and one or more databases.
-Derby databases live in a
+As the following figure shows,
+ databases live in a
system, which includes system-wide properties, an error log, and one or more
-databases.
-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.
+databases.
+Derby system
+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.
+
The system directory can also contain an error log file called derby.log (see ).
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 database
directories that are used by the software.
An example of a database
-directory and file structure.
-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.
+directory and file structure
+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.
+
imposes relatively
few limitations on the number and size of databases and database objects.
The following table shows some size limitations of
databases
-and database objects:
+and database objects.
Size limits for
database objects
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.
- supports the ParameterMetaData interface,
-new in JDBC 3.0. This interface describes the number, type, and properties
+
+ supports the
+ParameterMetaData interface. This interface describes the number, type, and properties
of prepared statement parameters. See the for
more information.
- A connection need only
-compile a PreparedStatement onceSubsequent executions
-can use the same statement execution plan even if the parameter values are
-different. (PreparedStatements are not shared across connections.)
-This figure shows one connection
-with multiple executions of the same PreparedStatement, which uses the same
-statement execution plan.
+A connection need only compile a PreparedStatement once. Subsequent
+executions can use the same statement execution plan even if the parameter
+values are different, as shown in the following figure.
+(PreparedStatements are not shared across connections.)
+Prepared statements and the
+statement cache
+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.
- Even if your statement uses Statements instead of PreparedStatements, can reuse the statement
@@ -65,17 +66,19 @@ meet the following requirements:
The Unicode flag that the statement was compiled under must match the
current connection's flag
-
+
If your application executes statements that are almost
but not exactly alike, it is more efficient to use PreparedStatements with
dynamic or IN parameters.
-A database can reuse a statement
-execution plan when the SQL text matches a prior statement exactly
-(PreparedStatements are much more efficient.)
-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 following figure shows how
+ can reuse a statement
+execution plan that is already in the statement cache when the SQL text matches
+a prior statement exactly, even when the statement is executed from a
+different connection. PreparedStatements are much more efficient,
+however.
+Statements and the statement
+cache
+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.