Return-Path: Delivered-To: apmail-db-derby-commits-archive@www.apache.org Received: (qmail 77718 invoked from network); 1 Jul 2005 09:17:05 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 1 Jul 2005 09:17:05 -0000 Received: (qmail 45750 invoked by uid 500); 1 Jul 2005 09:17:03 -0000 Delivered-To: apmail-db-derby-commits-archive@db.apache.org Received: (qmail 45692 invoked by uid 500); 1 Jul 2005 09:17:02 -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 45558 invoked by uid 500); 1 Jul 2005 09:17:01 -0000 Delivered-To: apmail-incubator-derby-cvs@incubator.apache.org Received: (qmail 45505 invoked by uid 99); 1 Jul 2005 09:17:01 -0000 X-ASF-Spam-Status: No, hits=0.2 required=10.0 tests=NO_REAL_NAME X-Spam-Check-By: apache.org Received: from [209.237.227.194] (HELO minotaur.apache.org) (209.237.227.194) by apache.org (qpsmtpd/0.29) with SMTP; Fri, 01 Jul 2005 02:16:54 -0700 Received: (qmail 77517 invoked by uid 65534); 1 Jul 2005 09:16:52 -0000 Message-ID: <20050701091652.77516.qmail@minotaur.apache.org> Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: svn commit: r208734 [3/4] - in /incubator/derby/docs/trunk/src: adminguide/ devguide/ getstart/ ref/ tools/ Date: Fri, 01 Jul 2005 09:16:00 -0000 To: derby-cvs@incubator.apache.org From: fuzzylogic@apache.org X-Mailer: svnmailer-1.0.2 X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Modified: incubator/derby/docs/trunk/src/devguide/cdevstandards805841.dita URL: http://svn.apache.org/viewcvs/incubator/derby/docs/trunk/src/devguide/cdevstandards805841.dita?rev=208734&r1=208733&r2=208734&view=diff ============================================================================== --- incubator/derby/docs/trunk/src/devguide/cdevstandards805841.dita (original) +++ incubator/derby/docs/trunk/src/devguide/cdevstandards805841.dita Fri Jul 1 02:15:43 2005 @@ -1,6 +1,6 @@ - - -Fewer reserved keywords - - - -

has converted several keywords to be -non-reserved.

- Modified: incubator/derby/docs/trunk/src/devguide/cdevstandards805949.dita URL: http://svn.apache.org/viewcvs/incubator/derby/docs/trunk/src/devguide/cdevstandards805949.dita?rev=208734&r1=208733&r2=208734&view=diff ============================================================================== --- incubator/derby/docs/trunk/src/devguide/cdevstandards805949.dita (original) +++ incubator/derby/docs/trunk/src/devguide/cdevstandards805949.dita Fri Jul 1 02:15:43 2005 @@ -1,6 +1,6 @@ - - + CLOB, and BLOB - - + -

supports the standard CLOB and BLOB data types.

- +

supports the standard +CLOB and BLOB data types. BLOB and CLOB values are limited to a maximum of +2,147,483,647 characters.

+ + Modified: incubator/derby/docs/trunk/src/devguide/cdevstandards806001.dita URL: http://svn.apache.org/viewcvs/incubator/derby/docs/trunk/src/devguide/cdevstandards806001.dita?rev=208734&r1=208733&r2=208734&view=diff ============================================================================== --- incubator/derby/docs/trunk/src/devguide/cdevstandards806001.dita (original) +++ incubator/derby/docs/trunk/src/devguide/cdevstandards806001.dita Fri Jul 1 02:15:43 2005 @@ -1,6 +1,6 @@ - - + Deployment options and threading and connection modes - -Deployment modesthreading/connection modes -and -Multi-threaded applications -Multiple connectionsfrom single application -running in embedded modefrom multiple applications -connecting to server - - - +Deployment modesthreading/connection modes +andMulti-threaded applications +Multiple connectionsfrom single application running +in embedded modefrom multiple applications connecting +to server + -

A database can be available to multiple connections in the following situations:

-
    -
  • Multiple applications access a single database (possible only when is -running inside a server framework).
    • -
  • A single application has more than one Connection to -the same database. -

    The way you deploy affects the ways applications -can use multi-threading and connections, as shown in .

    - -Threading and -Connection Modes - - - - +

    A database can be available to multiple connections in the following +situations:

    +
      +
    • Multiple applications access a single database (possible only when is running inside a server +framework).
      • +
    • A single application has more than one Connection to the same database. +

      The way you deploy affects +the ways applications can use multi-threading and connections, as shown in .

    Threading and Connection Modes + + Connection mode -Embedded -Server +Embedded +Server + - -

    Multi-Threaded

    -

    From an -application, using a single Connection to a database and issuing requests against -that connection in multiple threads.

     -Supply a single Connection object -to separate threads. ensures that only one operation is applied -at a time for consistency. Server frameworks automatically manage multi-threaded -operations. For more information, see . +

    Multi-Threaded

    From an application, using +a single Connection to a database +and issuing requests against that connection in multiple threads.

     +Supply a single Connection object to separate threads. ensures that only one +operation is applied at a time for consistency. Server frameworks automatically +manage multi-threaded operations. For more information, see . Server frameworks can automatically multi-thread operations. -Remote client applications can multi-thread if desired.     +Remote client applications can multi-thread if desired. + - -

    Multi-Connection

    -

    From -an application, using multiple connections to a database and issuing -requests against those connections on multiple threads.

    -

    (You must have -a multi-user license to have more than one connection to .)

     +

    Multi-Connection

    From an application, using +multiple connections to a database +and issuing requests against those connections on multiple threads.

     Create individual connections within a single application and use the appropriate connection for each JDBC request. The connections -can all be to the same database, or can be to different databases in the same system. +can all be to the same database, or can be to different databases in the same system. Remote client applications can establish the multiple connections -desired.     +desired. + - -

    Multi-User

    -

    Multiple applications -(or JVMs) accessing the same database. Each user application has -its own connection or connections to the database.

     +

    Multi-User

    Multiple applications (or JVMs) +accessing the same database. +Each user application has its own connection or connections to the database.

     Not possible. Only one application can access a database at a time, and only one application can access a specific system at a time. -When using a pre-1.4 JVM, might not prevent multiple applications -from concurrently accessing the same system, but do not allow +When using a pre-1.4 JVM, might +not prevent multiple applications from concurrently accessing the same system, but do not allow this because such access can corrupt the databases involved. Only one server should access a database at a time. Multiple remote client applications can access the same server, and thus can access -the same database at the same time through that server.     +the same database at the same time through that server. +
- + + Modified: incubator/derby/docs/trunk/src/devguide/rdevconcepts8424.dita URL: http://svn.apache.org/viewcvs/incubator/derby/docs/trunk/src/devguide/rdevconcepts8424.dita?rev=208734&r1=208733&r2=208734&view=diff ============================================================================== --- incubator/derby/docs/trunk/src/devguide/rdevconcepts8424.dita (original) +++ incubator/derby/docs/trunk/src/devguide/rdevconcepts8424.dita Fri Jul 1 02:15:43 2005 @@ -1,6 +1,6 @@ - - + Simple non-updatable ResultSets - - + -

Here is an excerpt from a sample JDBC application that generates a ResultSet with a simple SELECT statement and then processes -the rows.

-Connection conn = DriverManager.getConnection( +

Here is an excerpt from a sample JDBC application that generates +a ResultSet with a simple SELECT statement and then processes the rows.

+ Connection conn = DriverManager.getConnection( "jdbc:derby:sample"); Statement s = conn.createStatement(); s.execute("set schema 'SAMP'"); //note that autocommit is on--it is on by default in JDBC ResultSet rs = s.executeQuery( "SELECT empno, firstnme, lastname, salary, bonus, comm " - + 12 "FROM samp.employee"); + + "FROM samp.employee"); /** a standard JDBC ResultSet. It maintains a * cursor that points to the current row of data. The cursor * moves down one row each time the method next() is called. @@ -56,4 +56,5 @@ // the transaction commits automatically and releases //shared locks s.close(); - + + Modified: incubator/derby/docs/trunk/src/devguide/rdevconceptsholdablecursors.dita URL: http://svn.apache.org/viewcvs/incubator/derby/docs/trunk/src/devguide/rdevconceptsholdablecursors.dita?rev=208734&r1=208733&r2=208734&view=diff ============================================================================== --- incubator/derby/docs/trunk/src/devguide/rdevconceptsholdablecursors.dita (original) +++ incubator/derby/docs/trunk/src/devguide/rdevconceptsholdablecursors.dita Fri Jul 1 02:15:43 2005 @@ -1,6 +1,6 @@ - - - Copyright -First Edition (August 2004) +First Edition (July 2005) -

Copyright 1997, 2004 The Apache Software Foundation or its licensors, +

Copyright 1997, 2005 The Apache Software Foundation or its licensors, as applicable.

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License athttp://www.apache.org/licenses/LICENSE-2.0

Unless @@ -32,4 +30,3 @@ the specific language governing permissions and limitations under the License.

- Modified: incubator/derby/docs/trunk/src/devguide/rdevcsecure125.dita URL: http://svn.apache.org/viewcvs/incubator/derby/docs/trunk/src/devguide/rdevcsecure125.dita?rev=208734&r1=208733&r2=208734&view=diff ============================================================================== --- incubator/derby/docs/trunk/src/devguide/rdevcsecure125.dita (original) +++ incubator/derby/docs/trunk/src/devguide/rdevcsecure125.dita Fri Jul 1 02:15:43 2005 @@ -1,6 +1,6 @@ - - + User authentication example in a single-user, embedded environment - - + -

In this example, is embedded in a single-user application that -is deployed in a number of different and potentially insecure ways. For that -reason, the application developer has decided to encrypt the database and -to turn on user authentication using 's built-in user authentication, +

In this example, is +embedded in a single-user application that is deployed in a number of different +and potentially insecure ways. For that reason, the application developer +has decided to encrypt the database and to turn on user authentication using 's built-in user authentication, which will not require connections to an LDAP server. The end-user must know -the bootPassword to boot the database and the user -name and password to connect to the database. Even if the database ended up -in an e-mail, only the intended recipient would be able to access data in -the database. The application developer has decided not to use any user authorization -features, since each database will accept only a single user. In that situation, -the default full-access connection mode is acceptable.

-

When creating the database, the application developer encrypts the database -by using the following connection URL:

-jdbc:derby:wombat;create=true;dataEncryption=true; +the bootPassword to boot the database and the user name and password +to connect to the database. Even if the database ended up in an e-mail, only +the intended recipient would be able to access data in the database. The application +developer has decided not to use any user authorization features, since each +database will accept only a single user. In that situation, the default full-access +connection mode is acceptable.

+

When creating the database, the application developer encrypts +the database by using the following connection URL:

+ jdbc:derby:wombat;create=true;dataEncryption=true; bootPassword=sxy90W348HHn -

Before deploying the database, the application developer turns on user -authentication, sets the authentication provider to BUILTIN, creates a single -user and password, and disallows system-wide properties to protect the database-wide -security property settings:

-SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY( +

Before deploying the database, the application developer turns +on user authentication, sets the authentication provider to BUILTIN, creates +a single user and password, and disallows system-wide properties to protect +the database-wide security property settings:

+ CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY( 'derby.connection.requireAuthentication', 'true') -SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY( +CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY( 'derby.authentication.provider', 'BUILTIN') -SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY( +CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY( 'derby.user.enduser', 'red29PlaNe') CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY( 'derby.database.propertiesOnly', true') -

When the user connects (and boots) the database, the user has to provide -the bootPassword, the user name, and the password. -The following example shows how to provide those in a connection URL, although the -application programmer would probably provide GUI windows to allow the end -user to type those in:

-jdbc:derby:wombat;bootPassword=sxy90W348HHn; +

When the user connects (and boots) the database, the user has +to provide the bootPassword, the user name, and the password. The following +example shows how to provide those in a connection URL, although the application +programmer would probably provide GUI windows to allow the end user to type +those in:

+ jdbc:derby:wombat;bootPassword=sxy90W348HHn; user=enduser;password=red29PlaNe - + + Modified: incubator/derby/docs/trunk/src/devguide/rdevcsecure190.dita URL: http://svn.apache.org/viewcvs/incubator/derby/docs/trunk/src/devguide/rdevcsecure190.dita?rev=208734&r1=208733&r2=208734&view=diff ============================================================================== --- incubator/derby/docs/trunk/src/devguide/rdevcsecure190.dita (original) +++ incubator/derby/docs/trunk/src/devguide/rdevcsecure190.dita Fri Jul 1 02:15:43 2005 @@ -1,6 +1,6 @@ - - + Libraries for LDAP user authentication - -jndidrequired for LDAP user authorization +jndidrequired for LDAP user authorization ldap.jarrequired for LDAP user authorization -providerutil.jarrequired for LDAP user -authentication +providerutil.jarrequired for LDAP user authentication - - + -

To use an LDAP directory service with , you need the following -libraries in your classpath:

-
    -
  • jndi.jar -

    JNDI classes

    • -
  • ldap.jar -

    LDAP provider from Sun

    • -
  • providerutil.jar -

    JNDI classes for a provider

    • +

    To use an LDAP directory service with , +you need the following libraries in your classpath:

    +
      +
    • jndi.jar

      JNDI classes

      • +
    • ldap.jar

      LDAP provider from Sun

      • +
    • providerutil.jar

      JNDI classes for a provider

    -

    does not provide these libraries; they are available from Sun on -the JNDI page at Use the 1.1.x versions of these libraries, not the 1.2.x -versions. You might need to do two separate downloads to obtain all the required -libraries.

    - +

    does +not provide these libraries; they are available from Sun on the JNDI page. +Use the 1.1.x versions of these libraries, not the 1.2.x versions. You might +need to do two separate downloads to obtain all the required libraries.

    + + Modified: incubator/derby/docs/trunk/src/devguide/rdevcsecure622.dita URL: http://svn.apache.org/viewcvs/incubator/derby/docs/trunk/src/devguide/rdevcsecure622.dita?rev=208734&r1=208733&r2=208734&view=diff ============================================================================== --- incubator/derby/docs/trunk/src/devguide/rdevcsecure622.dita (original) +++ incubator/derby/docs/trunk/src/devguide/rdevcsecure622.dita Fri Jul 1 02:15:43 2005 @@ -1,6 +1,6 @@ - Trademarks -

    The following terms are trademarks of International Business Machines Corporation -in the United States, other countries, or both, and have been used in at least -one of the documents in the DB2 UDB documentation library.

    - - - - -Cloudscape -DB2 -DB2 Universal Database - - DRDA -IBM -WebSphere - - - -

    The following terms are trademarks or registered trademarks of other companies and have been used in at least one of the documents in the documentation library:

    +

    Cloudscape, DB2, DB2 Universal Database, DRDA, and IBM are trademarks of +International Business Machines Corporation in the United States, other countries, +or both.

    Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.

    Java and all Java-based trademarks are trademarks of Sun Microsystems, @@ -52,4 +35,3 @@ of others.

     - Modified: incubator/derby/docs/trunk/src/devguide/tdevconcepts41704.dita URL: http://svn.apache.org/viewcvs/incubator/derby/docs/trunk/src/devguide/tdevconcepts41704.dita?rev=208734&r1=208733&r2=208734&view=diff ============================================================================== --- incubator/derby/docs/trunk/src/devguide/tdevconcepts41704.dita (original) +++ incubator/derby/docs/trunk/src/devguide/tdevconcepts41704.dita Fri Jul 1 02:15:43 2005 @@ -1,6 +1,8 @@ + - - Naming or accessing the name of a cursor @@ -31,20 +30,22 @@ the setCursorName method of the Statement interface. You assign the name to a cursor before executing the Statement that will generate it.

    Statement s3 = conn.createStatement(); -// name the statement so we can reference the result set -// it generates +// name the statement so we can reference the result set +// it generates s3.setCursorName("UPDATABLESTATEMENT"); -// we will be able to use the following statement later -//to access the current row of the cursor +// we will be able to use the following statement later +// to access the current row of the cursor +// a result set needs to be obtained prior to using the +// WHERE CURRENT syntax +ResultSet rs = s3.executeQuery("select * from + FlightBookings FOR UPDATE of number_seats"); PreparedStatement ps2 = conn.prepareStatement( - "UPDATE FlightBookings SET number_seats = ? " + - "WHERE CURRENT OF UPDATABLESTATEMENT");

    Typically, you + "UPDATE FlightBookings SET number_seats = ? " + + "WHERE CURRENT OF UPDATABLESTATEMENT");

    Typically, you do not assign a name to the cursor, but let the system generate one for you automatically. You can determine the system-generated cursor name of a ResultSet generated -by a SELECT statement using the ResultSet class's getCursorName method.

    PreparedStatement ps2 = conn.prepareStatement( +by a SELECT statement using the ResultSet class's getCursorName method.

    PreparedStatement ps2 = conn.prepareStatement( "UPDATE employee SET bonus = ? WHERE CURRENT OF "+ Updatable.getCursorName());     - Modified: incubator/derby/docs/trunk/src/devguide/tdevconcepts839040.dita URL: http://svn.apache.org/viewcvs/incubator/derby/docs/trunk/src/devguide/tdevconcepts839040.dita?rev=208734&r1=208733&r2=208734&view=diff ============================================================================== --- incubator/derby/docs/trunk/src/devguide/tdevconcepts839040.dita (original) +++ incubator/derby/docs/trunk/src/devguide/tdevconcepts839040.dita Fri Jul 1 02:15:43 2005 @@ -1,6 +1,6 @@