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 Fri, 25 Aug 2006 16:07:17 GMT

Andreas Korneliussen (JIRA) wrote:
>      [ http://issues.apache.org/jira/browse/DERBY-1696?page=all ]
> Andreas Korneliussen updated DERBY-1696:
> ----------------------------------------
>     Component/s: Store
> To fix this issue, I need a mechanism to notify the store (scancontroller) to move off
the row (i.e to afterLast() or beforeFirst()), so that it can release the lock on the current
> I do consider the following options:
> Alternative 1: 
> Use the method ScanController.positionAtRowLocation(RowLocation rl)
> Here the RowLocation objects could represent the positions beforeFirst and afterLast.
I.e one could make use of the 
> RecordHandle. RESERVED4_RECORD_HANDLE to represent to beforeFirst and afterLast positions.
> When the method ScanController.positionAtRowLocation(RowLocation rl), is called with
a rowlocation with these  positions,
> the scan implementation may release the U-lock of the current row
> Alternative 2:
> Add new methods to ScanController interface: moveToAfterLast() and moveToBeforeFirst()

Can you just close the scan if you don't need it positioned anymore?
>>transaction may sometimes keep lock on a row after moving off the resultset in scrollable
updatable resultset
>>                Key: DERBY-1696
>>                URL: http://issues.apache.org/jira/browse/DERBY-1696
>>            Project: Derby
>>         Issue Type: Bug
>>         Components: SQL, Store
>>   Affects Versions:,,
>>           Reporter: Andreas Korneliussen
>>        Assigned To: Andreas Korneliussen
>>If an application does the following:
>> Statement s = con.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE, 
>>                                          ResultSet.CONCUR_UPDATABLE);
>> ResultSet rs = s.executeQuery("select * from t1");
>> rs.afterLast();
>> rs.last();
>> rs.next();
>>After doing this in transaction isolation level read-committed/read-uncommitted, the
last row is still locked with an update lock.
>>This is detected by running the JUnit testcase ConcurrencyTest.testUpdatePurgedTuple1
in the DerbyNetClient framework.
>>(NOTE: the bug is revealed by this test, because the network server does a rs.last()
as the first operation on a scrollable updatable resultset to count number of rows)
>>What triggers this bug, seems to be the repositioning of the cursor after the underlying
all records have been inserted into the hashtable from the source scan. When moving off the
result set (to afterLast() or beforeFirst()) no action is done to release the lock of the
current row.

View raw message