svn commit: r451706 - /db/derby/docs/trunk/src/devguide/rdevconcepts8424.dita

[fu...@apache.org]

Author: fuzzylogic
Date: Sat Sep 30 18:25:18 2006
New Revision: 451706

URL: http://svn.apache.org/viewvc?view=rev&rev=451706
Log:
DERBY-1683: Fix incorrect statement about scope of locks for TRANSACTION_REPEATABLE_READ in the Developer's Guide.

Committed for Laura Stewart <sc...@gmail.com>

Modified:
    db/derby/docs/trunk/src/devguide/rdevconcepts8424.dita

Modified: db/derby/docs/trunk/src/devguide/rdevconcepts8424.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/devguide/rdevconcepts8424.dita?view=diff&rev=451706&r1=451705&r2=451706
==============================================================================
--- db/derby/docs/trunk/src/devguide/rdevconcepts8424.dita (original)
+++ db/derby/docs/trunk/src/devguide/rdevconcepts8424.dita Sat Sep 30 18:25:18 2006
@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="utf-8"?>
-
+ 
 <!DOCTYPE reference PUBLIC "-//OASIS//DTD DITA Reference//EN"
  "../dtd/reference.dtd">
 <!-- 
@@ -22,47 +22,57 @@
 <title>Scope of locks</title>
 <shortdesc>The amount of data locked by a statement can vary.</shortdesc>
 <prolog><metadata>
-<keywords><indexterm>Locks<indexterm>scope of</indexterm></indexterm></keywords>
+<keywords><indexterm>locks<indexterm>table-level</indexterm></indexterm><indexterm>locks<indexterm>row-level</indexterm></indexterm>
+<indexterm>locks<indexterm>range</indexterm></indexterm><indexterm>table-level
+locks</indexterm><indexterm>row-level locks</indexterm><indexterm>range locks</indexterm>
+<indexterm>isolation levels<indexterm>REPEATABLE_READ</indexterm></indexterm>
+<indexterm>isolation levels<indexterm>READ_COMMITTED</indexterm></indexterm>
+<indexterm>isolation levels<indexterm>SERIALIZABLE</indexterm></indexterm>
+<indexterm>isolation levels<indexterm>READ_UNCOMMITTED</indexterm></indexterm>
+<indexterm>transactions<indexterm>isolation levels</indexterm></indexterm>
+</keywords>
 </metadata></prolog>
 <refbody>
-<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
+<section><title>Table locks</title><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
+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
+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
+conref="devconrefs.dita#pub/cittuning"></ph></cite>.</p></section>
+<section><title>Single-row locks</title><p>A statement can lock only <i>a
+single row</i> at a time.</p><p>For row-level locking systems:<ul>
+<li>For TRANSACTION_REPEATABLE_READ isolation, the locks are released at the
+end of the transaction.</li>
+<li>For TRANSACTION_READ_COMMITTED isolation, <ph conref="devconrefs.dita#prod/productshortname"></ph> 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.</li>
+<li>For TRANSACTION_SERIALIZABLE isolation, however, <ph conref="devconrefs.dita#prod/productshortname"></ph> locks
+the whole set before the application begins stepping through.</li>
+<li>For TRANSACTION_READ_UNCOMMITTED, no row locks are requested.</li>
+</ul> </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
+is committed. If there is an index associated with the table, the previous
+key is also locked.</p></section>
+<section><title>Range locks</title><p>A statement can lock <i>a range of rows</i> (range
+lock).</p><p>For row-level locking systems: <ul>
+<li>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.</li>
+<li>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 frame="all" id="cdevconcepts15873"><title>Possible
-Types and Scopes of Locking</title>
+to prevent nonrepeatable reads and phantoms.</li>
+</ul></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 frame="all" id="cdevconcepts15873"><title>Types
+and scopes of locking</title>
 <tgroup cols="3" colsep="1" rowsep="1"><colspec colname="1" colnum="1" colwidth="1159*"/>
 <colspec colname="2" colnum="2" colwidth="979*"/><colspec colname="3" colnum="3"
 colwidth="1759*"/>
@@ -75,15 +85,14 @@
 </thead>
 <tbody>
 <row>
-<entry colname="1">Connection. TRANSACTION_ READ_UNCOMMITED (SQL: UR)</entry>
+<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>
+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="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
@@ -94,15 +103,15 @@
 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="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="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>
@@ -113,7 +122,6 @@
 </row>
 </tbody>
 </tgroup>
-</table></li>
-</ul></section>
+</table></section>
 </refbody>
 </reference>