[
https://issues.apache.org/jira/browse/DERBY-1696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-1696:
--------------------------------------
Issue & fix info: [Repro attached]
Triaged for 10.5.2.
> transaction may sometimes keep lock on a row after moving off the resultset
> in scrollable updatable resultset
> -------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1696
> URL: https://issues.apache.org/jira/browse/DERBY-1696
> Project: Derby
> Issue Type: Bug
> Components: SQL, Store
> Affects Versions: 10.2.1.6, 10.2.2.0, 10.3.1.4
> Reporter: 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.
-
You can reply to this email to add a comment to the issue online.
