[ http://issues.apache.org/jira/browse/DERBY-1696?page=all ]
Andreas Korneliussen updated DERBY-1696: ---------------------------------------- Assignee: (was: Andreas Korneliussen) > 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.5, 10.2.2.0, 10.3.0.0 > 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. - 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