[ http://issues.apache.org/jira/browse/DERBY-1696?page=comments#action_12431886 ] Fernanda Pizzorno commented on DERBY-1696: ------------------------------------------
The locks are not being released when an index is being used to access the table. You can reproduce this failure by changing the test you have added so that the select statement selects only the table's primary key (indexed column). I think it would be good to run this new test with all the data models used in SURQueryMixTest. > 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.3.0.0, 10.2.2.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
