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] Updated: (DERBY-1696) transaction may sometimes keep lock on a row after moving off the resultset in scrollable updatable resultset
Date Tue, 29 Aug 2006 15:25:55 GMT
Mike Matrigali wrote:
> The current interface to reopen a heap scan at the beginning
> is reopenScan(), I think it is confusing to change
> positionAtRowLocation(null) to also do this.
> Does your usage want the table level intent lock released or not?

The usage requires that the table level intent lock is not released.

> Because previously this code was never triggered by user code
> the heap implmentation does the unlocking in the fetchRows
> side which was always called immediately after the reopen.  Now that
> a user can indirectly cause a reopen and a fetch in separate statements
> it is reasonable to move the release of the lock to the reopen rather
> than delay it to the next fetch.
> Note the reopenScan() logic the btree case already does the unlocking
> here (code is completely different than heap case, so can't be copied).
> To reposition a heap scan at the beginning you should just be able to
> call:
> reopenScan() with mostly null args, this is the standard way most heap
> scans are positioned at the beginning.
> Does your code use the reopenScanByRowLocation interfaces, I don't
> think this code is doing unlocking in read committed correctly either.

The code does not use reopenScanByRowLocation(..), it uses
positionAtRowLocation(..) which uses a private method
"reopenScanByRecordHandleAndSetLocks" which does unlocking and locking.

I have prepared a patch which uses reopenScan(). Since reopenScan() sets
the scan state to SCAN_INIT or SCAN_HOLD_INIT, I do also need to update
some of the logic which was added w.r.t holdability:

reopenAfterEndTransaction() assumes that if the scan state is in
SCAN_HOLD_INIT, no RowLocations have been read, and therefore it is not
necessary to set the rowlocationsInvalidated flag. Since we now will use
reopenScan() when moving to beforeFirst / afterLast, this does not hold,
and the flag must also be set in these cases as well.


> /mikem
> Andreas Korneliussen wrote:
>>>> Can you just close the scan if you don't need it positioned anymore?
>>> I'll check if that works
>> The problem is that we need it re-positioned later, i.e if the user
>> moves to the afterLast() position and then scrolls to any other row, we
>> need to lock that row.
>> If the scan has been closed with close(), we cannot reopen it. If it has
>> been closed with closeForEndTransaction(.) we may reopen it, however
>> that would be quite undesirable, since we are not ending the
>> transaction, and we do not access the scancontroller from ScanManager
>> (which has closeForEndTransaction(.).
>> An alternative which I have considered is to make
>> ScanController.positionAtRowLocation(..) handle this by adding semantics
>> to the RowLocation being NULL.
>> I.e in HeapScan.java add this:
>>  public boolean positionAtRowLocation(RowLocation rl) throws
>> StandardException {
>>         if (rl==null)
>>         {
>>             positionAtDoneScan(scan_position);
>>             return(false);
>>         }
>> positionAtDoneScan will set the scan state to SCAN_DONE and release lock
>> as desired.
>> Andreas

View raw message