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.
> 

Agree.

>> 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:


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

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

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

Andreas

Mime
View raw message