[ http://issues.apache.org/jira/browse/DERBY-1696?page=all ]
Andreas Korneliussen updated DERBY-1696:
----------------------------------------
Attachment: DERBY-1696.diff
DERBY-1696.stat
The attached patch addresses this bug by having the SQL-execution layer use
ScanController.reopenScan() to release the lock.
In the store layer, GenericScanController.reopenScan() has been modified to
release the read-lock after read, while
GenericScanController.reopenAfterEndTransaction() now additonally may set the
rowLocations invalidated flag even if the scan_state is SCAN_HOLD_INIT. This is
because previously the scan_state SCAN_HOLD_INIT would (as it was used)
guarantee that no RowLocations had been read from the scan.
Testing: one new test added to ConcurrencyTest. HoldabilityTest had to be
modified: if a compress happens, and there is an open scrollable updatable
resultset, no updates will be allowed, even if no scrolling has happened.
> 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
> Attachments: DERBY-1696.diff, DERBY-1696.stat
>
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
