db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: [jira] Updated: (DERBY-1696) transaction may sometimes keep lock on a row after moving off the resultset in scrollable updatable resultset
Date Mon, 28 Aug 2006 15:46:11 GMT
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?

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


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