db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From kahat...@apache.org
Subject svn commit: r775937 - in /db/derby/code/trunk/java/engine/org/apache/derby/impl/store/access/btree: BTreeLockingPolicy.java index/B2IRowLocking3.java
Date Mon, 18 May 2009 13:18:21 GMT
Author: kahatlen
Date: Mon May 18 13:18:20 2009
New Revision: 775937

URL: http://svn.apache.org/viewvc?rev=775937&view=rev
DERBY-4177: Javadoc for BTreeLockingPolicy should not mention "scan lock"

The fix for DERBY-2991 removed the concept of a "scan lock" and
RECORD_ID_PROTECTION_HANDLE, so the javadoc for the BTreeLockingPolicy
class hierarchy should not mention them anymore.


Modified: db/derby/code/trunk/java/engine/org/apache/derby/impl/store/access/btree/BTreeLockingPolicy.java
URL: http://svn.apache.org/viewvc/db/derby/code/trunk/java/engine/org/apache/derby/impl/store/access/btree/BTreeLockingPolicy.java?rev=775937&r1=775936&r2=775937&view=diff
--- db/derby/code/trunk/java/engine/org/apache/derby/impl/store/access/btree/BTreeLockingPolicy.java
+++ db/derby/code/trunk/java/engine/org/apache/derby/impl/store/access/btree/BTreeLockingPolicy.java
Mon May 18 13:18:20 2009
@@ -24,7 +24,6 @@
 import org.apache.derby.iapi.error.StandardException; 
 import org.apache.derby.iapi.store.raw.FetchDescriptor;
-import org.apache.derby.iapi.store.raw.RecordHandle;
 import org.apache.derby.iapi.types.DataValueDescriptor;
 import org.apache.derby.iapi.types.RowLocation;
@@ -44,23 +43,23 @@
 There are 2 types of lock interfaces, lockScan*() and lockNonScan*().
-The lockScan*() interfaces assume that the caller gets a "scan lock" on the
-page before requesting any row locks on the page.  This is either done by
-makeing a lockScan() call followed by row lock requests, or it can be done
-in one operation by calling lockScanRow() and requesting the scan lock be
-obtained before getting the row lock.  Upon return from these interfaces 
+The lockScan*() interfaces save the key for the current scan position before
+giving up the latch on the page if they have to wait for a row lock. The
+callers can reposition the scan using the saved key by calling
+{@code BTreeScan.reposition()} if such a situation occurs. Then the latches
+are reobtained, possibly on a different page if the current key has been moved
+to another page in the meantime. Upon return from these interfaces
 the row lock requested is guaranteed to have been obtained on the correct
 key for the row requested.  These interfaces handle the special case of 
 unique indexes where the RowLocation can change while waiting on the lock 
 (see implementation for details), basically the lock is retryed after waiting
 if the RowLocation has changed.
-The lockNonScan*() interfaces assume that no "scan lock" exists.  If these
+The lockNonScan*() interfaces do not save the current scan position. If these
 routines return that the latch was released while waiting to obtain the
 lock, then the caller must requeue the lock request after taking appropriate
 action.  This action usually involves researching the tree to make sure 
-that the correct key is locked with latches held.  Because no scan lock is
-held the original row could have disappeared from the table.  These interfaces
+that the correct key is locked with latches held. These interfaces
 do not handle the special case of unique indexes where the RowLocation can 
 change while waiting on the lock, as the row may disappear when the latch
 is released to wait on the lock - thus it is necessary that the caller retry

Modified: db/derby/code/trunk/java/engine/org/apache/derby/impl/store/access/btree/index/B2IRowLocking3.java
URL: http://svn.apache.org/viewvc/db/derby/code/trunk/java/engine/org/apache/derby/impl/store/access/btree/index/B2IRowLocking3.java?rev=775937&r1=775936&r2=775937&view=diff
--- db/derby/code/trunk/java/engine/org/apache/derby/impl/store/access/btree/index/B2IRowLocking3.java
+++ db/derby/code/trunk/java/engine/org/apache/derby/impl/store/access/btree/index/B2IRowLocking3.java
Mon May 18 13:18:20 2009
@@ -818,14 +818,9 @@
                 // The previous key is on a previous page, search left 
                 // through the pages to find the key to latch.
-                // RESOLVE RLL (mikem) - do I need to do the 
-                // RECORD_ID_PROTECTION_HANDLE lock.
-                // First guarantee that record id's will not move off this
-                // current page while searching for previous key, by getting
-                // the RECORD_ID_PROTECTION_HANDLE lock on the current page.
-                // Since we have a latch on the cur
-                // RESOLVE RLL (mikem) - NO RECORD_ID PROTECTION IN EFFECT.
+                // If we need to release the latches while searching left,
+                // a new key may have appeared in the range that we've already
+                // searched, or the tree may have been rearranged, so the
                 // caller must research, get new locks if this routine 
                 // releases latches.
                 ret_status = this.searchLeftAndLockPreviousKey(

View raw message