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 row.
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 and
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: 10.2.1.0, 10.2.2.0, 10.3.0.0
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.
