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
Affects Versions: 10.2.0.0, 10.2.2.0, 10.3.0.0
Reporter: Andreas Korneliussen
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
