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 jt...@apache.org on 2005/03/31 02:27:29 UTC
svn commit: r159548 [9/17] - in incubator/derby/docs/trunk/src: adminguide/
devguide/ getstart/ tuning/
Modified: incubator/derby/docs/trunk/src/devguide/rdevconcepts38274.dita
URL: http://svn.apache.org/viewcvs/incubator/derby/docs/trunk/src/devguide/rdevconcepts38274.dita?view=diff&r1=159547&r2=159548
==============================================================================
--- incubator/derby/docs/trunk/src/devguide/rdevconcepts38274.dita (original)
+++ incubator/derby/docs/trunk/src/devguide/rdevconcepts38274.dita Wed Mar 30 16:26:36 2005
@@ -1,63 +1,63 @@
-<?xml version="1.0" encoding="utf-8"?>
-<!--
-Copyright 1997, 2004 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 at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an "AS IS" BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.
--->
-<!DOCTYPE reference PUBLIC "-//IBM//DTD DITA Reference//EN" "../dtd/reference.dtd">
-<reference xml:lang="en-us" id="rdevconcepts38274">
-<title>Extended updatable cursor example</title>
-<prolog>
-</prolog>
-<refbody><example>
-<codeblock>String URL = "jdbc:derby:sample";
-<b>// autocommit must be turned off for updatable cursors</b>
-conn.setAutoCommit(false);
-Statement s3 = conn.createStatement();
-<b>// name the statement so we can reference the result set
-// it generates</b>
-s3.setCursorName("UPDATABLESTATEMENT");
-<b>// Updatable statements have some requirements</b>
-<b>// for example, select must be on a single table</b>
-ResultSet Updatable = s3.executeQuery(
- "SELECT firstnme, lastname, workdept, bonus" +
- "FROM employee FOR UPDATE of bonus");
-<b>// we need a separate statement to do the</b>
-<b>// update PreparedStatement</b>
-PreparedStatement ps2 = conn.prepareStatement("UPDATE employee " +
-<b>// we could use the cursor name known by the system,</b>
-<b>// as the following line shows</b>
-<b>//"SET bonus = ? WHERE CURRENT OF " + Updatable.getCursorName());</b>
-<b>// but we already know the cursor name</b>
-"SET bonus = ? WHERE CURRENT OF UPDATABLESTATEMENT");
-String theDept="E21";
-while (Updatable.next()) {
- String firstnme = Updatable.getString("FIRSTNME");
- String lastName = Updatable.getString("LASTNAME");
- String workDept = Updatable.getString("WORKDEPT");
- BigDecimal bonus = Updatable.getBigDecimal("BONUS");
- if (workDept.equals(theDept)) {
- <b>// if the current row meets our criteria,
- // update the updatable column in the row</b>
- ps2.setBigDecimal(1, bonus.add(new BigDecimal(250)));
- ps2.executeUpdate();
- System.out.println("Updating bonus in employee" +
- " table for employee " + firstnme +
- ", department " + theDept );
- }
- }
-Updatable.close();
-s3.close();
-ps2.close();
-conn.commit();</codeblock></example>
-</refbody></reference>
+<?xml version="1.0" encoding="utf-8"?>
+<!--
+Copyright 1997, 2004 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 at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+-->
+<!DOCTYPE reference PUBLIC "-//IBM//DTD DITA Reference//EN" "../dtd/reference.dtd">
+<reference xml:lang="en-us" id="rdevconcepts38274">
+<title>Extended updatable cursor example</title>
+<prolog>
+</prolog>
+<refbody><example>
+<codeblock>String URL = "jdbc:derby:sample";
+<b>// autocommit must be turned off for updatable cursors</b>
+conn.setAutoCommit(false);
+Statement s3 = conn.createStatement();
+<b>// name the statement so we can reference the result set
+// it generates</b>
+s3.setCursorName("UPDATABLESTATEMENT");
+<b>// Updatable statements have some requirements</b>
+<b>// for example, select must be on a single table</b>
+ResultSet Updatable = s3.executeQuery(
+ "SELECT firstnme, lastname, workdept, bonus" +
+ "FROM employee FOR UPDATE of bonus");
+<b>// we need a separate statement to do the</b>
+<b>// update PreparedStatement</b>
+PreparedStatement ps2 = conn.prepareStatement("UPDATE employee " +
+<b>// we could use the cursor name known by the system,</b>
+<b>// as the following line shows</b>
+<b>//"SET bonus = ? WHERE CURRENT OF " + Updatable.getCursorName());</b>
+<b>// but we already know the cursor name</b>
+"SET bonus = ? WHERE CURRENT OF UPDATABLESTATEMENT");
+String theDept="E21";
+while (Updatable.next()) {
+ String firstnme = Updatable.getString("FIRSTNME");
+ String lastName = Updatable.getString("LASTNAME");
+ String workDept = Updatable.getString("WORKDEPT");
+ BigDecimal bonus = Updatable.getBigDecimal("BONUS");
+ if (workDept.equals(theDept)) {
+ <b>// if the current row meets our criteria,
+ // update the updatable column in the row</b>
+ ps2.setBigDecimal(1, bonus.add(new BigDecimal(250)));
+ ps2.executeUpdate();
+ System.out.println("Updating bonus in employee" +
+ " table for employee " + firstnme +
+ ", department " + theDept );
+ }
+ }
+Updatable.close();
+s3.close();
+ps2.close();
+conn.commit();</codeblock></example>
+</refbody></reference>
Propchange: incubator/derby/docs/trunk/src/devguide/rdevconcepts38274.dita
------------------------------------------------------------------------------
svn:eol-style = native
Modified: incubator/derby/docs/trunk/src/devguide/rdevconcepts600.dita
URL: http://svn.apache.org/viewcvs/incubator/derby/docs/trunk/src/devguide/rdevconcepts600.dita?view=diff&r1=159547&r2=159548
==============================================================================
--- incubator/derby/docs/trunk/src/devguide/rdevconcepts600.dita (original)
+++ incubator/derby/docs/trunk/src/devguide/rdevconcepts600.dita Wed Mar 30 16:26:36 2005
@@ -1,53 +1,53 @@
-<?xml version="1.0" encoding="utf-8"?>
-<!--
-Copyright 1997, 2004 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 at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an "AS IS" BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.
--->
-<!DOCTYPE reference PUBLIC "-//IBM//DTD DITA Reference//EN" "../dtd/reference.dtd">
-<reference xml:lang="en-us" id="rdevconcepts600">
-<title>Example of threads sharing a statement</title>
-<prolog><metadata>
-<keywords>
-<indexterm>Statements shared by threads<indexterm>dangers of</indexterm></indexterm>
-</keywords>
-</metadata>
-</prolog>
-<refbody>
-<section><p>This example shows what can happen if two threads try to share a single<i> Statement</i>.</p></section><example>
-<codeblock>PreparedStatement ps = conn.prepareStatement(
- "UPDATE account SET balance = balance + ? WHERE id = ?");
-<b>/* now assume two threads T1,T2 are given this
-java.sql.PreparedStatement object </b>and that the following events
-happen in the order shown (pseudojava code)*/
-T1 - ps.setBigDecimal(1, 100.00);
-T1 - ps.setLong(2, 1234);
-T2 - ps.setBigDecimal(1, -500.00);
-<b>// *** At this point the prepared statement has the parameters
-// -500.00 and 1234
-// T1 thinks it is adding 100.00 to account 1234 but actually
-// it is subtracting 500.00</b>
-T1 - ps.executeUpdate();
-T2 - ps.setLong(2, 5678);
-<b>// T2 executes the correct update</b>
- T2 - ps.executeUpdate();
-<b>/* Also, the auto-commit mode of the connection can lead
-to some strange behavior.*/</b></codeblock></example>
-<section><p>If it is absolutely necessary, the application can get around this problem
-with Java synchronization.</p></section>
-<section><p>If the threads each obtain their own <i>PreparedStatement</i> (with identical text), their <codeph><i>setXXX</i></codeph> calls
-do not interfere with each other. Moreover, <ph conref="devconrefs.dita#prod/productshortname"></ph> is able to share the
-same compiled query plan between the two statements; it needs to maintain
-only separate state information. However, there is the potential for confusion
-in regard to the timing of the <i>commit</i>, since a single <i>commit</i> commits all the statements in a transaction.</p></section>
-</refbody></reference>
+<?xml version="1.0" encoding="utf-8"?>
+<!--
+Copyright 1997, 2004 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 at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+-->
+<!DOCTYPE reference PUBLIC "-//IBM//DTD DITA Reference//EN" "../dtd/reference.dtd">
+<reference xml:lang="en-us" id="rdevconcepts600">
+<title>Example of threads sharing a statement</title>
+<prolog><metadata>
+<keywords>
+<indexterm>Statements shared by threads<indexterm>dangers of</indexterm></indexterm>
+</keywords>
+</metadata>
+</prolog>
+<refbody>
+<section><p>This example shows what can happen if two threads try to share a single<i> Statement</i>.</p></section><example>
+<codeblock>PreparedStatement ps = conn.prepareStatement(
+ "UPDATE account SET balance = balance + ? WHERE id = ?");
+<b>/* now assume two threads T1,T2 are given this
+java.sql.PreparedStatement object </b>and that the following events
+happen in the order shown (pseudojava code)*/
+T1 - ps.setBigDecimal(1, 100.00);
+T1 - ps.setLong(2, 1234);
+T2 - ps.setBigDecimal(1, -500.00);
+<b>// *** At this point the prepared statement has the parameters
+// -500.00 and 1234
+// T1 thinks it is adding 100.00 to account 1234 but actually
+// it is subtracting 500.00</b>
+T1 - ps.executeUpdate();
+T2 - ps.setLong(2, 5678);
+<b>// T2 executes the correct update</b>
+ T2 - ps.executeUpdate();
+<b>/* Also, the auto-commit mode of the connection can lead
+to some strange behavior.*/</b></codeblock></example>
+<section><p>If it is absolutely necessary, the application can get around this problem
+with Java synchronization.</p></section>
+<section><p>If the threads each obtain their own <i>PreparedStatement</i> (with identical text), their <codeph><i>setXXX</i></codeph> calls
+do not interfere with each other. Moreover, <ph conref="devconrefs.dita#prod/productshortname"></ph> is able to share the
+same compiled query plan between the two statements; it needs to maintain
+only separate state information. However, there is the potential for confusion
+in regard to the timing of the <i>commit</i>, since a single <i>commit</i> commits all the statements in a transaction.</p></section>
+</refbody></reference>
Propchange: incubator/derby/docs/trunk/src/devguide/rdevconcepts600.dita
------------------------------------------------------------------------------
svn:eol-style = native
Modified: incubator/derby/docs/trunk/src/devguide/rdevconcepts713.dita
URL: http://svn.apache.org/viewcvs/incubator/derby/docs/trunk/src/devguide/rdevconcepts713.dita?view=diff&r1=159547&r2=159548
==============================================================================
--- incubator/derby/docs/trunk/src/devguide/rdevconcepts713.dita (original)
+++ incubator/derby/docs/trunk/src/devguide/rdevconcepts713.dita Wed Mar 30 16:26:36 2005
@@ -1,97 +1,97 @@
-<?xml version="1.0" encoding="utf-8"?>
-<!--
-Copyright 1997, 2004 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 at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an "AS IS" BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.
--->
-<!DOCTYPE reference PUBLIC "-//IBM//DTD DITA Reference//EN" "../dtd/reference.dtd">
-<reference xml:lang="en-us" id="rdevconcepts713">
-<title>Deployment options and threading and connection modes</title>
-<prolog><metadata>
-<keywords>
-<indexterm>Deployment modes<indexterm>threading/connection modes
-and</indexterm></indexterm>
-<indexterm>Multi-threaded applications</indexterm>
-<indexterm>Multiple connections<indexterm>from single application
-running in embedded mode</indexterm><indexterm>from multiple applications
-connecting to server</indexterm></indexterm>
-</keywords>
-</metadata>
-</prolog>
-<refbody>
-<section><p>A database can be available to multiple connections in the following situations:</p></section><section>
-<ul>
-<li>Multiple applications access a single database (possible only when <ph conref="devconrefs.dita#prod/productshortname"></ph> is
-running inside a server framework).</li>
-<li>A single application has more than one <i>Connection</i> to
-the same database.
-<p>The way you deploy <ph conref="devconrefs.dita#prod/productshortname"></ph> affects the ways applications
-can use multi-threading and connections, as shown in <xref href="#rdevconcepts713/cdevconcepts40343"/>.</p>
-<table id="cdevconcepts40343" frame="all">
-<title>Threading and
-Connection Modes</title>
-<tgroup cols="3" colsep="1" rowsep="1">
-<colspec colnum="1" colname="1" colwidth="36*"/>
-<colspec colnum="2" colname="2" colwidth="37*"/>
-<colspec colnum="3" colname="3" colwidth="27*"/>
-<thead>
-<row>
-<entry colname="1">Connection mode</entry>
-<entry colname="2" valign="bottom" align="left">Embedded</entry>
-<entry colname="3" valign="bottom" align="left">Server</entry></row>
-</thead>
-<tbody>
-<row>
-<entry colname="1">
-<p><i>Multi-Threaded</i></p>
-<p>From an
-application, using a <i>single</i> <codeph><i>Connection</i></codeph> to a <ph conref="devconrefs.dita#prod/productshortname"></ph> database and issuing requests against
-that connection in multiple threads.</p></entry>
-<entry colname="2">Supply a single <i>Connection</i> object
-to separate threads. <ph conref="devconrefs.dita#prod/productshortname"></ph> ensures that only one operation is applied
-at a time for consistency. Server frameworks automatically manage multi-threaded
-operations. For more information, see <xref href="cdevconcepts19173.dita#cdevconcepts19173"/>.</entry>
-<entry colname="3">Server frameworks can automatically multi-thread operations.
-Remote client applications can multi-thread if desired.</entry></row>
-<row>
-<entry colname="1">
-<p><i>Multi-Connection</i></p>
-<p>From
-an application, using multiple connections to a <ph conref="devconrefs.dita#prod/productshortname"></ph> database and issuing
-requests against those connections on multiple threads.</p>
-<p>(You must have
-a multi-user license to have more than one connection to <ph conref="devconrefs.dita#prod/productshortname"></ph>.)</p></entry>
-<entry colname="2">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 <ph conref="devconrefs.dita#prod/productshortname"></ph> system.</entry>
-<entry colname="3">Remote client applications can establish the multiple connections
-desired.</entry></row>
-<row>
-<entry colname="1">
-<p><i>Multi-User</i></p>
-<p>Multiple applications
-(or JVMs) accessing the same <ph conref="devconrefs.dita#prod/productshortname"></ph> database. Each user application has
-its own connection or connections to the database.</p></entry>
-<entry colname="2">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, <ph conref="devconrefs.dita#prod/productshortname"></ph> might not prevent multiple applications
-from concurrently accessing the same <ph conref="devconrefs.dita#prod/productshortname"></ph> system, but do not allow
-this because such access can corrupt the databases involved.</entry>
-<entry colname="3">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.</entry></row>
-</tbody>
-</tgroup>
-</table></li>
-</ul></section>
-</refbody></reference>
+<?xml version="1.0" encoding="utf-8"?>
+<!--
+Copyright 1997, 2004 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 at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+-->
+<!DOCTYPE reference PUBLIC "-//IBM//DTD DITA Reference//EN" "../dtd/reference.dtd">
+<reference xml:lang="en-us" id="rdevconcepts713">
+<title>Deployment options and threading and connection modes</title>
+<prolog><metadata>
+<keywords>
+<indexterm>Deployment modes<indexterm>threading/connection modes
+and</indexterm></indexterm>
+<indexterm>Multi-threaded applications</indexterm>
+<indexterm>Multiple connections<indexterm>from single application
+running in embedded mode</indexterm><indexterm>from multiple applications
+connecting to server</indexterm></indexterm>
+</keywords>
+</metadata>
+</prolog>
+<refbody>
+<section><p>A database can be available to multiple connections in the following situations:</p></section><section>
+<ul>
+<li>Multiple applications access a single database (possible only when <ph conref="devconrefs.dita#prod/productshortname"></ph> is
+running inside a server framework).</li>
+<li>A single application has more than one <i>Connection</i> to
+the same database.
+<p>The way you deploy <ph conref="devconrefs.dita#prod/productshortname"></ph> affects the ways applications
+can use multi-threading and connections, as shown in <xref href="#rdevconcepts713/cdevconcepts40343"/>.</p>
+<table id="cdevconcepts40343" frame="all">
+<title>Threading and
+Connection Modes</title>
+<tgroup cols="3" colsep="1" rowsep="1">
+<colspec colnum="1" colname="1" colwidth="36*"/>
+<colspec colnum="2" colname="2" colwidth="37*"/>
+<colspec colnum="3" colname="3" colwidth="27*"/>
+<thead>
+<row>
+<entry colname="1">Connection mode</entry>
+<entry colname="2" valign="bottom" align="left">Embedded</entry>
+<entry colname="3" valign="bottom" align="left">Server</entry></row>
+</thead>
+<tbody>
+<row>
+<entry colname="1">
+<p><i>Multi-Threaded</i></p>
+<p>From an
+application, using a <i>single</i> <codeph><i>Connection</i></codeph> to a <ph conref="devconrefs.dita#prod/productshortname"></ph> database and issuing requests against
+that connection in multiple threads.</p></entry>
+<entry colname="2">Supply a single <i>Connection</i> object
+to separate threads. <ph conref="devconrefs.dita#prod/productshortname"></ph> ensures that only one operation is applied
+at a time for consistency. Server frameworks automatically manage multi-threaded
+operations. For more information, see <xref href="cdevconcepts19173.dita#cdevconcepts19173"/>.</entry>
+<entry colname="3">Server frameworks can automatically multi-thread operations.
+Remote client applications can multi-thread if desired.</entry></row>
+<row>
+<entry colname="1">
+<p><i>Multi-Connection</i></p>
+<p>From
+an application, using multiple connections to a <ph conref="devconrefs.dita#prod/productshortname"></ph> database and issuing
+requests against those connections on multiple threads.</p>
+<p>(You must have
+a multi-user license to have more than one connection to <ph conref="devconrefs.dita#prod/productshortname"></ph>.)</p></entry>
+<entry colname="2">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 <ph conref="devconrefs.dita#prod/productshortname"></ph> system.</entry>
+<entry colname="3">Remote client applications can establish the multiple connections
+desired.</entry></row>
+<row>
+<entry colname="1">
+<p><i>Multi-User</i></p>
+<p>Multiple applications
+(or JVMs) accessing the same <ph conref="devconrefs.dita#prod/productshortname"></ph> database. Each user application has
+its own connection or connections to the database.</p></entry>
+<entry colname="2">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, <ph conref="devconrefs.dita#prod/productshortname"></ph> might not prevent multiple applications
+from concurrently accessing the same <ph conref="devconrefs.dita#prod/productshortname"></ph> system, but do not allow
+this because such access can corrupt the databases involved.</entry>
+<entry colname="3">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.</entry></row>
+</tbody>
+</tgroup>
+</table></li>
+</ul></section>
+</refbody></reference>
Propchange: incubator/derby/docs/trunk/src/devguide/rdevconcepts713.dita
------------------------------------------------------------------------------
svn:eol-style = native
Modified: incubator/derby/docs/trunk/src/devguide/rdevconcepts8424.dita
URL: http://svn.apache.org/viewcvs/incubator/derby/docs/trunk/src/devguide/rdevconcepts8424.dita?view=diff&r1=159547&r2=159548
==============================================================================
--- incubator/derby/docs/trunk/src/devguide/rdevconcepts8424.dita (original)
+++ incubator/derby/docs/trunk/src/devguide/rdevconcepts8424.dita Wed Mar 30 16:26:36 2005
@@ -1,122 +1,122 @@
-<?xml version="1.0" encoding="utf-8"?>
-<!--
-Copyright 1997, 2004 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 at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an "AS IS" BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.
--->
-<!DOCTYPE reference PUBLIC "-//IBM//DTD DITA Reference//EN" "../dtd/reference.dtd">
-<reference xml:lang="en-us" id="rdevconcepts8424">
-<title>Scope of locks</title>
-<prolog><metadata>
-<keywords>
-<indexterm>Locks<indexterm>scope of</indexterm></indexterm>
-</keywords>
-</metadata>
-</prolog>
-<refbody>
-<section><p>The amount of data locked by a statement can vary. </p></section><section>
-<ul>
-<li><i>table locks</i>
-<p>A statement can lock the <i>entire table</i>.</p>
-<p>Table-level locking systems always lock entire tables.</p>
-<p>Row-level locking systems can lock entire tables if the WHERE clause
-of a statement cannot use an index. For example, UPDATES that cannot use an
-index lock the entire table.</p>
-<p>Row-level locking systems can lock entire
-tables if a high number of single-row locks would be less efficient than a
-single table-level lock. Choosing table-level locking instead of row-level
-locking for performance reasons is called <i>lock escalation</i>. (For more information about this topic, see "About the System's
-Selection of Lock Granularity" and "Transaction-Based Lock Escalation"
-in <cite><ph conref="devconrefs.dita#pub/cittuning"></ph></cite>.)</p></li>
-<li><i>single-row locks</i>
-<p>A statement can lock only <i>a single row</i> at a time.</p>
-<p>This section applies only
-to row-level locking systems. </p>
-<p>For TRANSACTION_READ_COMMITTED or TRANSACTION_REPEATABLE_READ
-isolation, <ph conref="devconrefs.dita#prod/productshortname"></ph> treats rows as cursors for SELECT statements. It locks
-rows only as the application steps through the rows in the result. The current
-row is locked. The row lock is released when the application goes to the next
-row. (For TRANSACTION_SERIALIZABLE isolation, however, <ph conref="devconrefs.dita#prod/productshortname"></ph> locks the
-whole set before the application begins stepping through.) For TRANSACTION_READ_UNCOMMITTED,
-no row locks are requested.</p>
-<p><ph conref="devconrefs.dita#prod/productshortname"></ph> locks single rows for INSERT
-statements, holding each row until the transaction is committed. (If there
-is an index associated with the table, the previous key is also locked.)</p></li>
-<li><i>range locks</i>
-<p>A statement can lock <i>a range of rows</i> (range lock).</p>
-<p>This section applies only to row-level
-locking systems. </p>
-<p>For <i>any</i> isolation level, <ph conref="devconrefs.dita#prod/productshortname"></ph> locks <i>all the rows in the result</i> plus an entire range of rows
-for updates or deletes.</p>
-<p>For the TRANSACTION_SERIALIZABLE isolation level, <ph conref="devconrefs.dita#prod/productshortname"></ph> locks
-all the rows in the result plus an entire range of rows in the table for SELECTs
-to prevent nonrepeatable reads and phantoms.</p>
-<p>For example, if a SELECT
-statement specifies rows in the <i>Employee</i> table where
-the <i>salary</i> is BETWEEN two values, the system can lock
-more than just the actual rows it returns in the result. It also must lock
-the entire <i>range</i> of rows between those two values
-to prevent another transaction from inserting, deleting, or updating a row
-within that range.</p>
-<p>An index must be available for a range lock. If one
-is not available, <ph conref="devconrefs.dita#prod/productshortname"></ph> locks the entire table.</p>
-<table id="cdevconcepts15873" frame="all">
-<title>Possible Types and Scopes of Locking</title>
-<tgroup cols="3" colsep="1" rowsep="1">
-<colspec colnum="1" colname="1" colwidth="1159*"/>
-<colspec colnum="2" colname="2" colwidth="979*"/>
-<colspec colnum="3" colname="3" colwidth="1759*"/>
-<thead>
-<row>
-<entry colname="1" valign="bottom" align="left">Transaction Isolation Level</entry>
-<entry colname="2" valign="bottom" align="left">Table-Level Locking</entry>
-<entry colname="3" valign="bottom" align="left">Row-Level Locking</entry></row>
-</thead>
-<tbody>
-<row>
-<entry colname="1">Connection. TRANSACTION_ READ_UNCOMMITED (SQL: UR)</entry>
-<entry colname="2">For SELECT statements, table-level locking is never requested
-using this isolation level. For other statements, same as for TRANSACTION_
-READ_ COMMITTED.</entry>
-<entry colname="3">SELECT statements get no locks. For other statements, same
-as for TRANSACTION_ READ_COMMITTED.</entry></row>
-<row>
-<entry colname="1">Connection. TRANSACTION_ READ_COMMITTED (SQL: CS) </entry>
-<entry colname="2">SELECT statements get a shared lock on the entire table.
-The locks are released when the user closes the <i>ResultSet</i>. Other statements get exclusive locks on the entire table, which are
-released when the transaction commits.</entry>
-<entry colname="3">SELECTs lock and release single rows as the user steps
-through the <i>ResultSet</i>. UPDATEs and DELETEs get exclusive
-locks on a range of rows. INSERT statements get exclusive locks on single
-rows (and sometimes on the preceding rows).</entry></row>
-<row>
-<entry colname="1">Connection. TRANSACTION_ REPEATABLE_READ (SQL: RS)</entry>
-<entry colname="2">Same as for TRANSACTION_ SERIALIZABLE</entry>
-<entry colname="3">SELECT statements get shared locks on the rows that satisfy
-the WHERE clause (but do not prevent inserts into this range). UPDATEs and
-DELETEs get exclusive locks on a range of rows. INSERT statements get exclusive
-locks on single rows (and sometimes on the preceding rows).</entry></row>
-<row>
-<entry colname="1">Connection. TRANSACTION_ SERIALIZABLE (SQL: RR)</entry>
-<entry colname="2">SELECT statements get a shared lock on the entire table.
-Other statements get exclusive locks on the entire table, which are released
-when the transaction commits.</entry>
-<entry colname="3">SELECT statements get shared locks on a range of rows.
-UPDATE and DELETE statements get exclusive locks on a range of rows. INSERT
-statements get exclusive locks on single rows (and sometimes on the preceding
-rows).</entry></row>
-</tbody>
-</tgroup>
-</table></li>
-</ul></section>
-</refbody></reference>
+<?xml version="1.0" encoding="utf-8"?>
+<!--
+Copyright 1997, 2004 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 at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+-->
+<!DOCTYPE reference PUBLIC "-//IBM//DTD DITA Reference//EN" "../dtd/reference.dtd">
+<reference xml:lang="en-us" id="rdevconcepts8424">
+<title>Scope of locks</title>
+<prolog><metadata>
+<keywords>
+<indexterm>Locks<indexterm>scope of</indexterm></indexterm>
+</keywords>
+</metadata>
+</prolog>
+<refbody>
+<section><p>The amount of data locked by a statement can vary. </p></section><section>
+<ul>
+<li><i>table locks</i>
+<p>A statement can lock the <i>entire table</i>.</p>
+<p>Table-level locking systems always lock entire tables.</p>
+<p>Row-level locking systems can lock entire tables if the WHERE clause
+of a statement cannot use an index. For example, UPDATES that cannot use an
+index lock the entire table.</p>
+<p>Row-level locking systems can lock entire
+tables if a high number of single-row locks would be less efficient than a
+single table-level lock. Choosing table-level locking instead of row-level
+locking for performance reasons is called <i>lock escalation</i>. (For more information about this topic, see "About the System's
+Selection of Lock Granularity" and "Transaction-Based Lock Escalation"
+in <cite><ph conref="devconrefs.dita#pub/cittuning"></ph></cite>.)</p></li>
+<li><i>single-row locks</i>
+<p>A statement can lock only <i>a single row</i> at a time.</p>
+<p>This section applies only
+to row-level locking systems. </p>
+<p>For TRANSACTION_READ_COMMITTED or TRANSACTION_REPEATABLE_READ
+isolation, <ph conref="devconrefs.dita#prod/productshortname"></ph> treats rows as cursors for SELECT statements. It locks
+rows only as the application steps through the rows in the result. The current
+row is locked. The row lock is released when the application goes to the next
+row. (For TRANSACTION_SERIALIZABLE isolation, however, <ph conref="devconrefs.dita#prod/productshortname"></ph> locks the
+whole set before the application begins stepping through.) For TRANSACTION_READ_UNCOMMITTED,
+no row locks are requested.</p>
+<p><ph conref="devconrefs.dita#prod/productshortname"></ph> locks single rows for INSERT
+statements, holding each row until the transaction is committed. (If there
+is an index associated with the table, the previous key is also locked.)</p></li>
+<li><i>range locks</i>
+<p>A statement can lock <i>a range of rows</i> (range lock).</p>
+<p>This section applies only to row-level
+locking systems. </p>
+<p>For <i>any</i> isolation level, <ph conref="devconrefs.dita#prod/productshortname"></ph> locks <i>all the rows in the result</i> plus an entire range of rows
+for updates or deletes.</p>
+<p>For the TRANSACTION_SERIALIZABLE isolation level, <ph conref="devconrefs.dita#prod/productshortname"></ph> locks
+all the rows in the result plus an entire range of rows in the table for SELECTs
+to prevent nonrepeatable reads and phantoms.</p>
+<p>For example, if a SELECT
+statement specifies rows in the <i>Employee</i> table where
+the <i>salary</i> is BETWEEN two values, the system can lock
+more than just the actual rows it returns in the result. It also must lock
+the entire <i>range</i> of rows between those two values
+to prevent another transaction from inserting, deleting, or updating a row
+within that range.</p>
+<p>An index must be available for a range lock. If one
+is not available, <ph conref="devconrefs.dita#prod/productshortname"></ph> locks the entire table.</p>
+<table id="cdevconcepts15873" frame="all">
+<title>Possible Types and Scopes of Locking</title>
+<tgroup cols="3" colsep="1" rowsep="1">
+<colspec colnum="1" colname="1" colwidth="1159*"/>
+<colspec colnum="2" colname="2" colwidth="979*"/>
+<colspec colnum="3" colname="3" colwidth="1759*"/>
+<thead>
+<row>
+<entry colname="1" valign="bottom" align="left">Transaction Isolation Level</entry>
+<entry colname="2" valign="bottom" align="left">Table-Level Locking</entry>
+<entry colname="3" valign="bottom" align="left">Row-Level Locking</entry></row>
+</thead>
+<tbody>
+<row>
+<entry colname="1">Connection. TRANSACTION_ READ_UNCOMMITED (SQL: UR)</entry>
+<entry colname="2">For SELECT statements, table-level locking is never requested
+using this isolation level. For other statements, same as for TRANSACTION_
+READ_ COMMITTED.</entry>
+<entry colname="3">SELECT statements get no locks. For other statements, same
+as for TRANSACTION_ READ_COMMITTED.</entry></row>
+<row>
+<entry colname="1">Connection. TRANSACTION_ READ_COMMITTED (SQL: CS) </entry>
+<entry colname="2">SELECT statements get a shared lock on the entire table.
+The locks are released when the user closes the <i>ResultSet</i>. Other statements get exclusive locks on the entire table, which are
+released when the transaction commits.</entry>
+<entry colname="3">SELECTs lock and release single rows as the user steps
+through the <i>ResultSet</i>. UPDATEs and DELETEs get exclusive
+locks on a range of rows. INSERT statements get exclusive locks on single
+rows (and sometimes on the preceding rows).</entry></row>
+<row>
+<entry colname="1">Connection. TRANSACTION_ REPEATABLE_READ (SQL: RS)</entry>
+<entry colname="2">Same as for TRANSACTION_ SERIALIZABLE</entry>
+<entry colname="3">SELECT statements get shared locks on the rows that satisfy
+the WHERE clause (but do not prevent inserts into this range). UPDATEs and
+DELETEs get exclusive locks on a range of rows. INSERT statements get exclusive
+locks on single rows (and sometimes on the preceding rows).</entry></row>
+<row>
+<entry colname="1">Connection. TRANSACTION_ SERIALIZABLE (SQL: RR)</entry>
+<entry colname="2">SELECT statements get a shared lock on the entire table.
+Other statements get exclusive locks on the entire table, which are released
+when the transaction commits.</entry>
+<entry colname="3">SELECT statements get shared locks on a range of rows.
+UPDATE and DELETE statements get exclusive locks on a range of rows. INSERT
+statements get exclusive locks on single rows (and sometimes on the preceding
+rows).</entry></row>
+</tbody>
+</tgroup>
+</table></li>
+</ul></section>
+</refbody></reference>
Propchange: incubator/derby/docs/trunk/src/devguide/rdevconcepts8424.dita
------------------------------------------------------------------------------
svn:eol-style = native
Modified: incubator/derby/docs/trunk/src/devguide/rdevconcepts88082.dita
URL: http://svn.apache.org/viewcvs/incubator/derby/docs/trunk/src/devguide/rdevconcepts88082.dita?view=diff&r1=159547&r2=159548
==============================================================================
--- incubator/derby/docs/trunk/src/devguide/rdevconcepts88082.dita (original)
+++ incubator/derby/docs/trunk/src/devguide/rdevconcepts88082.dita Wed Mar 30 16:26:36 2005
@@ -1,59 +1,59 @@
-<?xml version="1.0" encoding="utf-8"?>
-<!--
-Copyright 1997, 2004 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 at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an "AS IS" BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.
--->
-<!DOCTYPE reference PUBLIC "-//IBM//DTD DITA Reference//EN" "../dtd/reference.dtd">
-<reference xml:lang="en-us" id="rdevconcepts88082">
-<title>Simple non-updatable ResultSets</title>
-<prolog>
-</prolog>
-<refbody>
-<section><p>Here is an excerpt from a sample JDBC application that generates a <i>ResultSet</i> with a simple SELECT statement and then processes
-the rows.</p></section><example>
-<codeblock>Connection conn = DriverManager.getConnection(
- "jdbc:derby:sample");
-Statement s = conn.createStatement();
-s.execute("set schema 'SAMP'");
-<b>//note that autocommit is on--it is on by default in JDBC</b>
-ResultSet rs = s.executeQuery(
- "SELECT empno, firstnme, lastname, salary, bonus, comm "
- + 12 "FROM samp.employee");
-<b>/** 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.
- * You can scroll one way only--forward--with the next()
- * method. When auto-commit is on, after you reach the
- * last row the statement is considered completed
- * and the transaction is committed.
- */</b>
-System.out.println( "last name" + "," + "first name" + ": earnings");
-<b>/* here we are scrolling through the result set
-with the next() method.*/</b>
-while (rs.next()) {
-<b> // processing the rows</b>
- String firstnme = rs.getString("FIRSTNME");
- String lastName = rs.getString("LASTNAME");
- BigDecimal salary = rs.getBigDecimal("SALARY");
- BigDecimal bonus = rs.getBigDecimal("BONUS");
- BigDecimal comm = rs.getBigDecimal("COMM");
- System.out.println( lastName + ", " + firstnme + ": "
- + (salary.add(bonus.add(comm))));
-}
-rs.close();
-<b>// once we've iterated through the last row,
-// the transaction commits automatically and releases
-//shared locks</b>
-s.close();</codeblock></example>
-</refbody></reference>
+<?xml version="1.0" encoding="utf-8"?>
+<!--
+Copyright 1997, 2004 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 at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+-->
+<!DOCTYPE reference PUBLIC "-//IBM//DTD DITA Reference//EN" "../dtd/reference.dtd">
+<reference xml:lang="en-us" id="rdevconcepts88082">
+<title>Simple non-updatable ResultSets</title>
+<prolog>
+</prolog>
+<refbody>
+<section><p>Here is an excerpt from a sample JDBC application that generates a <i>ResultSet</i> with a simple SELECT statement and then processes
+the rows.</p></section><example>
+<codeblock>Connection conn = DriverManager.getConnection(
+ "jdbc:derby:sample");
+Statement s = conn.createStatement();
+s.execute("set schema 'SAMP'");
+<b>//note that autocommit is on--it is on by default in JDBC</b>
+ResultSet rs = s.executeQuery(
+ "SELECT empno, firstnme, lastname, salary, bonus, comm "
+ + 12 "FROM samp.employee");
+<b>/** 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.
+ * You can scroll one way only--forward--with the next()
+ * method. When auto-commit is on, after you reach the
+ * last row the statement is considered completed
+ * and the transaction is committed.
+ */</b>
+System.out.println( "last name" + "," + "first name" + ": earnings");
+<b>/* here we are scrolling through the result set
+with the next() method.*/</b>
+while (rs.next()) {
+<b> // processing the rows</b>
+ String firstnme = rs.getString("FIRSTNME");
+ String lastName = rs.getString("LASTNAME");
+ BigDecimal salary = rs.getBigDecimal("SALARY");
+ BigDecimal bonus = rs.getBigDecimal("BONUS");
+ BigDecimal comm = rs.getBigDecimal("COMM");
+ System.out.println( lastName + ", " + firstnme + ": "
+ + (salary.add(bonus.add(comm))));
+}
+rs.close();
+<b>// once we've iterated through the last row,
+// the transaction commits automatically and releases
+//shared locks</b>
+s.close();</codeblock></example>
+</refbody></reference>
Propchange: incubator/derby/docs/trunk/src/devguide/rdevconcepts88082.dita
------------------------------------------------------------------------------
svn:eol-style = native
Modified: incubator/derby/docs/trunk/src/devguide/rdevconceptsholdablecursors.dita
URL: http://svn.apache.org/viewcvs/incubator/derby/docs/trunk/src/devguide/rdevconceptsholdablecursors.dita?view=diff&r1=159547&r2=159548
==============================================================================
--- incubator/derby/docs/trunk/src/devguide/rdevconceptsholdablecursors.dita (original)
+++ incubator/derby/docs/trunk/src/devguide/rdevconceptsholdablecursors.dita Wed Mar 30 16:26:36 2005
@@ -1,72 +1,72 @@
-<?xml version="1.0" encoding="utf-8"?>
-<!--
-Copyright 1997, 2004 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 at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an "AS IS" BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.
--->
-
-<!DOCTYPE reference PUBLIC "-//IBM//DTD DITA Reference//EN"
- "../dtd/reference.dtd">
-<reference id="rdevconceptsholdablecursors" xml:lang="en-us">
-<title>Holdable cursors</title>
-<prolog><metadata>
-<keywords><indexterm>Cursors<indexterm>holdable</indexterm></indexterm></keywords>
-</metadata></prolog>
-<refbody>
-<section> <note> Non-holdable cursors are only available in Java 2 Platform,
-Standard Edition, v 1.4 (J2SE) environments.</note></section>
-<section><p>The holdable cursor feature permits an application to keep cursors
-open after implicit or explicit commits. By default, the cursors are held
-open after a commit. Starting with Java<?Pub Caret?> 2 Platform, Standard
-Edition, v 1.4 (J2SE), cursors can be created with close when a commit occurs
-option. Such cursors will be automatically closed when a commit happens. Cursors
-are automatically closed when a transaction aborts, whether or not they have
-been specified to be held open.</p></section>
-<section> <note> Holdable cursors do not work with XA transactions, in <ph conref="devconrefs.dita#prod/productshortname"></ph>
-Version 10, therefore cursors should be opened with holdability false when
-working with XA transactions.</note></section>
-<section><p>To specify whether a cursor should be held open after a commit
-takes place, supply one of the following <i>ResultSet</i> parameters to the <codeph><i>Connection</i></codeph> method <codeph><i>createStatement</i
-></codeph>, <codeph><i>prepareStatement</i></codeph>, or <codeph><i>prepareCall</i></codeph>:</p></section>
-<section> <ul>
-<li><i><i>CLOSE_CURSORS_AT_COMMIT</i></i> <p>Cursors are closed when an
-implicit or explicit commit is performed.</p></li>
-<li><i><i>HOLD_CURSORS_OVER_COMMIT</i></i> <p>Cursors are held open when
-a commit is performed, implicitly or explicitly. This is the default behavior.</p></li>
-</ul></section>
-<section><p>The method <i>Statement.getResultSetHoldability()</i> indicates
-whether a cursor generated by the Statement object stays open or closes, upon
-commit. See the <cite><ph conref="devconrefs.dita#pub/citref"></ph></cite> for more information.</p></section>
-<section><p>When an implicit or explicit commit occurs, <i>ResultSets</i> that
-hold cursors open behave as follows:</p></section>
-<section> <ul>
-<li>Open <i>ResultSets</i> remain open. The cursor is positioned before the
-next logical row of the result set.</li>
-<li>When the session is terminated, the <i>ResultSet</i> is closed and destroyed.</li>
-<li>All locks are released, except locks protecting the current cursor position
-of open cursors specified to stay open after commits.</li>
-<li>Immediately following a commit, the only valid operations that can be
-performed on the <i>ResultSet</i> are: <ul>
-<li>positioning the <i>ResultSet</i> to the next valid row in the result with <codeph><i>ResultSet.next()</i></codeph>.</li>
-<li>closing the <i>ResultSet</i> with <codeph><i>ResultSet.close()</i></codeph>.</li>
-</ul></li>
-</ul></section>
-<section><p>When a rollback occurs either explicitly or implicitly, the following
-behavior applies:</p></section>
-<section> <ul>
-<li>All open <i>ResultSets</i> are closed.</li>
-<li>All locks acquired during the unit of work are released.</li>
-</ul></section>
-</refbody>
-</reference>
-<?Pub *0000003281?>
+<?xml version="1.0" encoding="utf-8"?>
+<!--
+Copyright 1997, 2004 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 at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+-->
+
+<!DOCTYPE reference PUBLIC "-//IBM//DTD DITA Reference//EN"
+ "../dtd/reference.dtd">
+<reference id="rdevconceptsholdablecursors" xml:lang="en-us">
+<title>Holdable cursors</title>
+<prolog><metadata>
+<keywords><indexterm>Cursors<indexterm>holdable</indexterm></indexterm></keywords>
+</metadata></prolog>
+<refbody>
+<section> <note> Non-holdable cursors are only available in Java 2 Platform,
+Standard Edition, v 1.4 (J2SE) environments.</note></section>
+<section><p>The holdable cursor feature permits an application to keep cursors
+open after implicit or explicit commits. By default, the cursors are held
+open after a commit. Starting with Java<?Pub Caret?> 2 Platform, Standard
+Edition, v 1.4 (J2SE), cursors can be created with close when a commit occurs
+option. Such cursors will be automatically closed when a commit happens. Cursors
+are automatically closed when a transaction aborts, whether or not they have
+been specified to be held open.</p></section>
+<section> <note> Holdable cursors do not work with XA transactions, in <ph conref="devconrefs.dita#prod/productshortname"></ph>
+Version 10, therefore cursors should be opened with holdability false when
+working with XA transactions.</note></section>
+<section><p>To specify whether a cursor should be held open after a commit
+takes place, supply one of the following <i>ResultSet</i> parameters to the <codeph><i>Connection</i></codeph> method <codeph><i>createStatement</i
+></codeph>, <codeph><i>prepareStatement</i></codeph>, or <codeph><i>prepareCall</i></codeph>:</p></section>
+<section> <ul>
+<li><i><i>CLOSE_CURSORS_AT_COMMIT</i></i> <p>Cursors are closed when an
+implicit or explicit commit is performed.</p></li>
+<li><i><i>HOLD_CURSORS_OVER_COMMIT</i></i> <p>Cursors are held open when
+a commit is performed, implicitly or explicitly. This is the default behavior.</p></li>
+</ul></section>
+<section><p>The method <i>Statement.getResultSetHoldability()</i> indicates
+whether a cursor generated by the Statement object stays open or closes, upon
+commit. See the <cite><ph conref="devconrefs.dita#pub/citref"></ph></cite> for more information.</p></section>
+<section><p>When an implicit or explicit commit occurs, <i>ResultSets</i> that
+hold cursors open behave as follows:</p></section>
+<section> <ul>
+<li>Open <i>ResultSets</i> remain open. The cursor is positioned before the
+next logical row of the result set.</li>
+<li>When the session is terminated, the <i>ResultSet</i> is closed and destroyed.</li>
+<li>All locks are released, except locks protecting the current cursor position
+of open cursors specified to stay open after commits.</li>
+<li>Immediately following a commit, the only valid operations that can be
+performed on the <i>ResultSet</i> are: <ul>
+<li>positioning the <i>ResultSet</i> to the next valid row in the result with <codeph><i>ResultSet.next()</i></codeph>.</li>
+<li>closing the <i>ResultSet</i> with <codeph><i>ResultSet.close()</i></codeph>.</li>
+</ul></li>
+</ul></section>
+<section><p>When a rollback occurs either explicitly or implicitly, the following
+behavior applies:</p></section>
+<section> <ul>
+<li>All open <i>ResultSets</i> are closed.</li>
+<li>All locks acquired during the unit of work are released.</li>
+</ul></section>
+</refbody>
+</reference>
+<?Pub *0000003281?>
Propchange: incubator/derby/docs/trunk/src/devguide/rdevconceptsholdablecursors.dita
------------------------------------------------------------------------------
svn:eol-style = native
Modified: incubator/derby/docs/trunk/src/devguide/rdevcopyright.dita
URL: http://svn.apache.org/viewcvs/incubator/derby/docs/trunk/src/devguide/rdevcopyright.dita?view=diff&r1=159547&r2=159548
==============================================================================
--- incubator/derby/docs/trunk/src/devguide/rdevcopyright.dita (original)
+++ incubator/derby/docs/trunk/src/devguide/rdevcopyright.dita Wed Mar 30 16:26:36 2005
@@ -1,35 +1,35 @@
-<?xml version="1.0" encoding="utf-8"?>
-<!--
-Copyright 1997, 2004 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 at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an "AS IS" BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.
--->
-
-<!DOCTYPE reference PUBLIC "-//IBM//DTD DITA Reference//EN"
- "../dtd/reference.dtd">
-<?Pub Inc?>
-<reference id="rdevcopyright" xml:lang="en-us">
-<title>Copyright</title>
-<shortdesc>First Edition (August 2004)</shortdesc>
-<refbody>
-<section><p>Copyright 1997, 2004 The Apache Software Foundation or its licensors,
-as applicable.</p><p>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 at<codeblock>http://www.apache.org/licenses/LICENSE-2.0</codeblock></p><p>Unless
-required by applicable law or agreed to in writing, software distributed
-under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES
-OR CONDITIONS OF ANY KIND, either express or implied. See the License for
-the specific language governing permissions and limitations under the License.<?Pub Caret?></p></section>
-</refbody>
-</reference>
-<?Pub *0000001046?>
+<?xml version="1.0" encoding="utf-8"?>
+<!--
+Copyright 1997, 2004 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 at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+-->
+
+<!DOCTYPE reference PUBLIC "-//IBM//DTD DITA Reference//EN"
+ "../dtd/reference.dtd">
+<?Pub Inc?>
+<reference id="rdevcopyright" xml:lang="en-us">
+<title>Copyright</title>
+<shortdesc>First Edition (August 2004)</shortdesc>
+<refbody>
+<section><p>Copyright 1997, 2004 The Apache Software Foundation or its licensors,
+as applicable.</p><p>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 at<codeblock>http://www.apache.org/licenses/LICENSE-2.0</codeblock></p><p>Unless
+required by applicable law or agreed to in writing, software distributed
+under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES
+OR CONDITIONS OF ANY KIND, either express or implied. See the License for
+the specific language governing permissions and limitations under the License.<?Pub Caret?></p></section>
+</refbody>
+</reference>
+<?Pub *0000001046?>
Propchange: incubator/derby/docs/trunk/src/devguide/rdevcopyright.dita
------------------------------------------------------------------------------
svn:eol-style = native
Modified: incubator/derby/docs/trunk/src/devguide/rdevcsecure125.dita
URL: http://svn.apache.org/viewcvs/incubator/derby/docs/trunk/src/devguide/rdevcsecure125.dita?view=diff&r1=159547&r2=159548
==============================================================================
--- incubator/derby/docs/trunk/src/devguide/rdevcsecure125.dita (original)
+++ incubator/derby/docs/trunk/src/devguide/rdevcsecure125.dita Wed Mar 30 16:26:36 2005
@@ -1,64 +1,64 @@
-<?xml version="1.0" encoding="utf-8"?>
-<!--
-Copyright 1997, 2004 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 at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an "AS IS" BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.
--->
-<!DOCTYPE reference PUBLIC "-//IBM//DTD DITA Reference//EN" "../dtd/reference.dtd">
-<reference xml:lang="en-us" id="rdevcsecure125">
-<title>User authentication example in a client/server environment</title>
-<prolog>
-</prolog>
-<refbody>
-<section><p>In this example, <ph conref="devconrefs.dita#prod/productshortname"></ph> is running in a user-designed application
-server. <ph conref="devconrefs.dita#prod/productshortname"></ph> provides the user authentication, not the application
-server. The server is running in a secure environment, the application server
-encrypts the passwords, and a database administrator is available. The administrator
-configures security using system-level properties in the <i>derby.properties</i> file and has protected this file with operating system
-tools. <ph conref="devconrefs.dita#prod/productshortname"></ph> connects to an existing LDAP directory service within the
-enterprise to authenticate users.</p></section>
-<section><p>The default access mode for all databases is set to <i>fullAccess</i> (the default).</p></section>
-<section><p>The <i>derby.properties</i> file for the server includes
-the following entries:</p></section><example>
-<codeblock><b># turn on user authentication</b>
-derby.connection.requireAuthentication=true
-<b># set the authentication provider to an external LDAP server</b>
-derby.authentication.provider=LDAP
-<b># the host name and port number of the LDAP server</b>
-derby.authentication.server=godfrey:389
-<b># the search base for user names</b>
-derby.authentication.ldap.searchBase=o=oakland.mycompany.com
-<b># explicitly show the access mode for databases (this is default)</b>
-derby.database.defaultAccessMode=fullAccess</codeblock></example>
-<section><p>With these settings, all users must be authenticated by the LDAP server
-in order to access any <ph conref="devconrefs.dita#prod/productshortname"></ph> databases.</p></section>
-<section><p>The database administrator has determined that one database, <i>accountingDB</i>, has additional security needs. Within a connection to that
-database, the database administrator uses database-wide properties (which
-override properties set in the <i>derby.properties</i> file)
-to limit access to this database. Only the users <i>prez</i>, <i>cfo</i>, and <i>numberCruncher</i> have full
-(read-write) access to this database, and only <i>clerk1</i> and <i>clerk2</i> have read-only access to this database. No other
-users can access the database.</p></section><example>
-<codeblock><b>CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY(
- 'derby.database.defaultAccessMode', 'noAccess')
-
-CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY(
- 'derby.database.fullAccessUsers',
- 'prez,cfo,numberCruncher')
-
-CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY(
- 'derby.database.readAccessUsers', 'clerk1,clerk2')</b></codeblock></example>
-<section><p>The database administrator then requires all current users to disconnect
-and re-connect. These property changes do not go into effect for current connections.
-The database administrator can force current users to reconnect by shutting
-down the database</p></section>
-</refbody></reference>
+<?xml version="1.0" encoding="utf-8"?>
+<!--
+Copyright 1997, 2004 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 at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+-->
+<!DOCTYPE reference PUBLIC "-//IBM//DTD DITA Reference//EN" "../dtd/reference.dtd">
+<reference xml:lang="en-us" id="rdevcsecure125">
+<title>User authentication example in a client/server environment</title>
+<prolog>
+</prolog>
+<refbody>
+<section><p>In this example, <ph conref="devconrefs.dita#prod/productshortname"></ph> is running in a user-designed application
+server. <ph conref="devconrefs.dita#prod/productshortname"></ph> provides the user authentication, not the application
+server. The server is running in a secure environment, the application server
+encrypts the passwords, and a database administrator is available. The administrator
+configures security using system-level properties in the <i>derby.properties</i> file and has protected this file with operating system
+tools. <ph conref="devconrefs.dita#prod/productshortname"></ph> connects to an existing LDAP directory service within the
+enterprise to authenticate users.</p></section>
+<section><p>The default access mode for all databases is set to <i>fullAccess</i> (the default).</p></section>
+<section><p>The <i>derby.properties</i> file for the server includes
+the following entries:</p></section><example>
+<codeblock><b># turn on user authentication</b>
+derby.connection.requireAuthentication=true
+<b># set the authentication provider to an external LDAP server</b>
+derby.authentication.provider=LDAP
+<b># the host name and port number of the LDAP server</b>
+derby.authentication.server=godfrey:389
+<b># the search base for user names</b>
+derby.authentication.ldap.searchBase=o=oakland.mycompany.com
+<b># explicitly show the access mode for databases (this is default)</b>
+derby.database.defaultAccessMode=fullAccess</codeblock></example>
+<section><p>With these settings, all users must be authenticated by the LDAP server
+in order to access any <ph conref="devconrefs.dita#prod/productshortname"></ph> databases.</p></section>
+<section><p>The database administrator has determined that one database, <i>accountingDB</i>, has additional security needs. Within a connection to that
+database, the database administrator uses database-wide properties (which
+override properties set in the <i>derby.properties</i> file)
+to limit access to this database. Only the users <i>prez</i>, <i>cfo</i>, and <i>numberCruncher</i> have full
+(read-write) access to this database, and only <i>clerk1</i> and <i>clerk2</i> have read-only access to this database. No other
+users can access the database.</p></section><example>
+<codeblock><b>CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY(
+ 'derby.database.defaultAccessMode', 'noAccess')
+
+CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY(
+ 'derby.database.fullAccessUsers',
+ 'prez,cfo,numberCruncher')
+
+CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY(
+ 'derby.database.readAccessUsers', 'clerk1,clerk2')</b></codeblock></example>
+<section><p>The database administrator then requires all current users to disconnect
+and re-connect. These property changes do not go into effect for current connections.
+The database administrator can force current users to reconnect by shutting
+down the database</p></section>
+</refbody></reference>
Propchange: incubator/derby/docs/trunk/src/devguide/rdevcsecure125.dita
------------------------------------------------------------------------------
svn:eol-style = native
Modified: incubator/derby/docs/trunk/src/devguide/rdevcsecure131.dita
URL: http://svn.apache.org/viewcvs/incubator/derby/docs/trunk/src/devguide/rdevcsecure131.dita?view=diff&r1=159547&r2=159548
==============================================================================
--- incubator/derby/docs/trunk/src/devguide/rdevcsecure131.dita (original)
+++ incubator/derby/docs/trunk/src/devguide/rdevcsecure131.dita Wed Mar 30 16:26:36 2005
@@ -1,51 +1,51 @@
-<?xml version="1.0" encoding="utf-8"?>
-<!--
-Copyright 1997, 2004 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 at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an "AS IS" BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.
--->
-<!DOCTYPE reference PUBLIC "-//IBM//DTD DITA Reference//EN" "../dtd/reference.dtd">
-<reference xml:lang="en-us" id="rdevcsecure131">
-<title>Examples of user authorization</title>
-<prolog>
-</prolog>
-<refbody>
-<section><p>This example shows the property settings to configure a database to support: </p></section><section>
-<ul>
-<li>Full access for a single user named "sa"</li>
-<li>Read-only access for anyone else who connects to the database
-<codeblock><b>CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY(
- 'derby.database.defaultConnectionMode',
- 'readOnlyAccess')</b>
-<b>CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY(
- 'derby.database.fullAccessUsers', 'sa')</b></codeblock></li>
-</ul></section>
-<section><p>The following example shows the settings to configure a database to support: </p></section><section>
-<ul>
-<li>Full access for a single user named "Fred!" (case-sensitive) with
-full (read-write) access </li>
-<li>Read-only access for mary and guest </li>
-<li>No access for other users</li>
-</ul></section>
-<section><p>The example also demonstrates the use of delimited identifiers for user
-names.</p></section><example>
-<codeblock><b>CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY(
- 'derby.database.defaultConnectionMode',
- 'noAccess')
-
-CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY(
- 'derby.database.fullAccessUsers', '"Fred!"')
-
-CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY(
- 'derby.database.readOnlyAccessUsers', 'mary,guest')</b></codeblock></example>
-</refbody></reference>
+<?xml version="1.0" encoding="utf-8"?>
+<!--
+Copyright 1997, 2004 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 at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+-->
+<!DOCTYPE reference PUBLIC "-//IBM//DTD DITA Reference//EN" "../dtd/reference.dtd">
+<reference xml:lang="en-us" id="rdevcsecure131">
+<title>Examples of user authorization</title>
+<prolog>
+</prolog>
+<refbody>
+<section><p>This example shows the property settings to configure a database to support: </p></section><section>
+<ul>
+<li>Full access for a single user named "sa"</li>
+<li>Read-only access for anyone else who connects to the database
+<codeblock><b>CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY(
+ 'derby.database.defaultConnectionMode',
+ 'readOnlyAccess')</b>
+<b>CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY(
+ 'derby.database.fullAccessUsers', 'sa')</b></codeblock></li>
+</ul></section>
+<section><p>The following example shows the settings to configure a database to support: </p></section><section>
+<ul>
+<li>Full access for a single user named "Fred!" (case-sensitive) with
+full (read-write) access </li>
+<li>Read-only access for mary and guest </li>
+<li>No access for other users</li>
+</ul></section>
+<section><p>The example also demonstrates the use of delimited identifiers for user
+names.</p></section><example>
+<codeblock><b>CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY(
+ 'derby.database.defaultConnectionMode',
+ 'noAccess')
+
+CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY(
+ 'derby.database.fullAccessUsers', '"Fred!"')
+
+CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY(
+ 'derby.database.readOnlyAccessUsers', 'mary,guest')</b></codeblock></example>
+</refbody></reference>
Propchange: incubator/derby/docs/trunk/src/devguide/rdevcsecure131.dita
------------------------------------------------------------------------------
svn:eol-style = native
Modified: incubator/derby/docs/trunk/src/devguide/rdevcsecure13713.dita
URL: http://svn.apache.org/viewcvs/incubator/derby/docs/trunk/src/devguide/rdevcsecure13713.dita?view=diff&r1=159547&r2=159548
==============================================================================
--- incubator/derby/docs/trunk/src/devguide/rdevcsecure13713.dita (original)
+++ incubator/derby/docs/trunk/src/devguide/rdevcsecure13713.dita Wed Mar 30 16:26:36 2005
@@ -1,60 +1,60 @@
-<?xml version="1.0" encoding="utf-8"?>
-<!--
-Copyright 1997, 2004 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 at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an "AS IS" BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.
--->
-<!DOCTYPE reference PUBLIC "-//IBM//DTD DITA Reference//EN" "../dtd/reference.dtd">
-<reference xml:lang="en-us" id="rdevcsecure13713">
-<title>User authentication example in a single-user, embedded environment</title>
-<prolog>
-</prolog>
-<refbody>
-<section><p>In this example, <ph conref="devconrefs.dita#prod/productshortname"></ph> 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 <ph conref="devconrefs.dita#prod/productshortname"></ph>'s built-in user authentication,
-which will not require connections to an LDAP server. The end-user must know
-the <i>bootPassword</i> 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.</p></section>
-<section><p>When creating the database, the application developer encrypts the database
-by using the following connection URL:</p></section><example>
-<codeblock><b>jdbc:derby:wombat;create=true;dataEncryption=true;
- bootPassword=sxy90W348HHn</b></codeblock></example>
-<section><p>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:</p></section><example>
-<codeblock><b>SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY(
- 'derby.connection.requireAuthentication', 'true')
-
-SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY(
- 'derby.authentication.provider', 'BUILTIN')
-
-SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY(
- 'derby.user.enduser', 'red29PlaNe')
-
-CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY(
- 'derby.database.propertiesOnly', true')</b></codeblock></example>
-<section><p>When the user connects (and boots) the database, the user has to provide
-the <i>bootPassword</i>, 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:</p></section><example>
-<codeblock><b>jdbc:derby:wombat;bootPassword=sxy90W348HHn;
- user=enduser;password=red29PlaNe</b></codeblock></example>
-</refbody></reference>
+<?xml version="1.0" encoding="utf-8"?>
+<!--
+Copyright 1997, 2004 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 at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+-->
+<!DOCTYPE reference PUBLIC "-//IBM//DTD DITA Reference//EN" "../dtd/reference.dtd">
+<reference xml:lang="en-us" id="rdevcsecure13713">
+<title>User authentication example in a single-user, embedded environment</title>
+<prolog>
+</prolog>
+<refbody>
+<section><p>In this example, <ph conref="devconrefs.dita#prod/productshortname"></ph> 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 <ph conref="devconrefs.dita#prod/productshortname"></ph>'s built-in user authentication,
+which will not require connections to an LDAP server. The end-user must know
+the <i>bootPassword</i> 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.</p></section>
+<section><p>When creating the database, the application developer encrypts the database
+by using the following connection URL:</p></section><example>
+<codeblock><b>jdbc:derby:wombat;create=true;dataEncryption=true;
+ bootPassword=sxy90W348HHn</b></codeblock></example>
+<section><p>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:</p></section><example>
+<codeblock><b>SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY(
+ 'derby.connection.requireAuthentication', 'true')
+
+SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY(
+ 'derby.authentication.provider', 'BUILTIN')
+
+SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY(
+ 'derby.user.enduser', 'red29PlaNe')
+
+CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY(
+ 'derby.database.propertiesOnly', true')</b></codeblock></example>
+<section><p>When the user connects (and boots) the database, the user has to provide
+the <i>bootPassword</i>, 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:</p></section><example>
+<codeblock><b>jdbc:derby:wombat;bootPassword=sxy90W348HHn;
+ user=enduser;password=red29PlaNe</b></codeblock></example>
+</refbody></reference>
Propchange: incubator/derby/docs/trunk/src/devguide/rdevcsecure13713.dita
------------------------------------------------------------------------------
svn:eol-style = native
Modified: incubator/derby/docs/trunk/src/devguide/rdevcsecure190.dita
URL: http://svn.apache.org/viewcvs/incubator/derby/docs/trunk/src/devguide/rdevcsecure190.dita?view=diff&r1=159547&r2=159548
==============================================================================
--- incubator/derby/docs/trunk/src/devguide/rdevcsecure190.dita (original)
+++ incubator/derby/docs/trunk/src/devguide/rdevcsecure190.dita Wed Mar 30 16:26:36 2005
@@ -1,76 +1,76 @@
-<?xml version="1.0" encoding="utf-8"?>
-<!--
-Copyright 1997, 2004 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 at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an "AS IS" BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.
--->
-<!DOCTYPE reference PUBLIC "-//IBM//DTD DITA Reference//EN" "../dtd/reference.dtd">
-<reference xml:lang="en-us" id="rdevcsecure190">
-<title>Read-only and full access permissions</title>
-<prolog><metadata>
-<keywords>
-<indexterm>Permissions</indexterm>
-<indexterm>Read-only access<indexterm>definition</indexterm></indexterm>
-<indexterm>Full access<indexterm>definition</indexterm></indexterm>
-</keywords>
-</metadata>
-</prolog>
-<refbody>
-<section><p><xref href="#rdevcsecure190/cdevcsecure20486"/> shows which actions read-only
-and full-access users are permitted to perform on regular or source databases
-and on target databases.</p></section>
-<table id="cdevcsecure20486" frame="all">
-<title>Permissions for Read-Only and Full-Access Users</title>
-<tgroup cols="3" colsep="1" rowsep="1">
-<colspec colnum="1" colname="1" colwidth="37*"/>
-<colspec colnum="2" colname="2" colwidth="21*"/>
-<colspec colnum="3" colname="3" colwidth="36*"/>
-<thead>
-<row>
-<entry colname="1" valign="bottom" align="left">Action</entry>
-<entry colname="2" valign="bottom" align="left">Read-Only Users</entry>
-<entry colname="3" valign="bottom" align="left">Full-Access Users</entry></row>
-</thead>
-<tbody>
-<row>
-<entry colname="1">Executing SELECT statements</entry>
-<entry colname="2">X</entry>
-<entry colname="3">X</entry></row>
-<row>
-<entry colname="1">Reading database properties</entry>
-<entry colname="2">X</entry>
-<entry colname="3">X</entry></row>
-<row>
-<entry colname="1">Loading database classes from jar files</entry>
-<entry colname="2">X</entry>
-<entry colname="3">X</entry></row>
-<row>
-<entry colname="1">Executing INSERT, UPDATE, or DELETE statements</entry>
-<entry colname="2"/>
-<entry colname="3">X</entry></row>
-<row>
-<entry colname="1">Executing DDL statements</entry>
-<entry colname="2"/>
-<entry colname="3">X</entry></row>
-<row>
-<entry colname="1">Adding or replacing jar files</entry>
-<entry colname="2"/>
-<entry colname="3">X</entry></row>
-<row>
-<entry colname="1">Setting database properties</entry>
-<entry colname="2"/>
-<entry colname="3">X</entry></row>
-</tbody>
-</tgroup>
-</table>
-</refbody></reference>
+<?xml version="1.0" encoding="utf-8"?>
+<!--
+Copyright 1997, 2004 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 at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+-->
+<!DOCTYPE reference PUBLIC "-//IBM//DTD DITA Reference//EN" "../dtd/reference.dtd">
+<reference xml:lang="en-us" id="rdevcsecure190">
+<title>Read-only and full access permissions</title>
+<prolog><metadata>
+<keywords>
+<indexterm>Permissions</indexterm>
+<indexterm>Read-only access<indexterm>definition</indexterm></indexterm>
+<indexterm>Full access<indexterm>definition</indexterm></indexterm>
+</keywords>
+</metadata>
+</prolog>
+<refbody>
+<section><p><xref href="#rdevcsecure190/cdevcsecure20486"/> shows which actions read-only
+and full-access users are permitted to perform on regular or source databases
+and on target databases.</p></section>
+<table id="cdevcsecure20486" frame="all">
+<title>Permissions for Read-Only and Full-Access Users</title>
+<tgroup cols="3" colsep="1" rowsep="1">
+<colspec colnum="1" colname="1" colwidth="37*"/>
+<colspec colnum="2" colname="2" colwidth="21*"/>
+<colspec colnum="3" colname="3" colwidth="36*"/>
+<thead>
+<row>
+<entry colname="1" valign="bottom" align="left">Action</entry>
+<entry colname="2" valign="bottom" align="left">Read-Only Users</entry>
+<entry colname="3" valign="bottom" align="left">Full-Access Users</entry></row>
+</thead>
+<tbody>
+<row>
+<entry colname="1">Executing SELECT statements</entry>
+<entry colname="2">X</entry>
+<entry colname="3">X</entry></row>
+<row>
+<entry colname="1">Reading database properties</entry>
+<entry colname="2">X</entry>
+<entry colname="3">X</entry></row>
+<row>
+<entry colname="1">Loading database classes from jar files</entry>
+<entry colname="2">X</entry>
+<entry colname="3">X</entry></row>
+<row>
+<entry colname="1">Executing INSERT, UPDATE, or DELETE statements</entry>
+<entry colname="2"/>
+<entry colname="3">X</entry></row>
+<row>
+<entry colname="1">Executing DDL statements</entry>
+<entry colname="2"/>
+<entry colname="3">X</entry></row>
+<row>
+<entry colname="1">Adding or replacing jar files</entry>
+<entry colname="2"/>
+<entry colname="3">X</entry></row>
+<row>
+<entry colname="1">Setting database properties</entry>
+<entry colname="2"/>
+<entry colname="3">X</entry></row>
+</tbody>
+</tgroup>
+</table>
+</refbody></reference>
Propchange: incubator/derby/docs/trunk/src/devguide/rdevcsecure190.dita
------------------------------------------------------------------------------
svn:eol-style = native