[ http://issues.apache.org/jira/browse/DERBY-1696?page=all ]
Andreas Korneliussen updated DERBY-1696:
----------------------------------------
Attachment: DERBY-1696v2.diff
The attached patch also releases the lock on indexed scans.
Additionally extended tests.
> 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, DERBY-1696v2.diff
>
>
> 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
