db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Korneliussen <Andreas.Kornelius...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-690) Add scrollable, updatable, insensitive result sets
Date Tue, 14 Mar 2006 13:36:19 GMT
Oystein Grovlen - Sun Norway wrote:
> Andreas Korneliussen (JIRA) wrote:
>>     [ 
>> http://issues.apache.org/jira/browse/DERBY-690?page=comments#action_12370325 
>> ]
>> Andreas Korneliussen commented on DERBY-690:
>> --------------------------------------------
>>> 11.2 positionAtRowLocation()
>>>      a) Why can not clients use the existing reopenScanByRowLocation
>>>         instead?
>> reopenScanByRowLocation(..) let the user reopen the scan and start 
>> scanning from the RowLocation specified. After a call to 
>> reopenScanByRowLocation(..) the rowLocation is not locked, the page is 
>> not latched, and the user need to call next() to get the next record.
>> This will actually be the next record after the rowLocation specified 
>> in reopenScanByRowLocation().
> Is this correct? OpenConglomerate.latchPageAndRepositionScan() will 
> position on the record before the specified position.


>> positionAtRowLocation(..) positions the scan, and locks the row. 
> So does the combination of reopenScanByRowLocation() and next().
>>> 12. GenericScanController
>>> 12.1 reopenScanByRecordHandleAndSetLocks()
>>>      a) If I have understood things correct, when a scan is initially
>>>         opened, the first row is not locked.  Locking happen on the
>>>         subsequent next().  Why could not a similar scheme be used
>>>         here? That is, reopen positions just before the specified row
>>>         and a subsequent call to next is performed to actually lock
>>>         it.  Looking at fetchRows() and the methods it calls, there
>>>         seems to already exist code to handle a repositioned scan.
>>>         (The combination of SCAN_INIT and a set record posisiton).
>> The combination of SCAN_INIT and a set record position will on the 
>> next() call move the rowlocation to the next row, not to the set 
>> record position.
>> If you position to a rowlocation which points to a previous row, and 
>> call next you may risk:
>> * on the next() call you skip the row if it has been deleted and 
>> return another row
> But could not this be detected and handled by the caller?

It could theoretically be detected by calling fetchRowLocation() after 
the next() and comparing it with the RowLocation specified.

Instead of scancontroller.positionAtRowLocation(rowLoc) you would get:

RowLocation cmp = scancontroller.newRowLocationTemplate();
if (!cmp.equals(rowLoc)) { // row deleted ?
   // need to go back to avoid that next() skips a row
   return false;
} else {
   return true;

I think it is preferrable to provide the positionAtRowLocation(..) method.

>> positionAtRowLocation() returns false if the row has been deleted.


View raw message