Uploaded image for project: 'Derby'
  1. Derby
  2. DERBY-1696

transaction may sometimes keep lock on a row after moving off the resultset in scrollable updatable resultset

    Details

    • Urgency:
      Normal
    • Issue & fix info:
      Repro attached

      Description

      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.

        Attachments

        1. DERBY-1696.diff
          7 kB
          Andreas Korneliussen
        2. DERBY-1696.stat
          0.5 kB
          Andreas Korneliussen
        3. DERBY-1696v2.diff
          11 kB
          Andreas Korneliussen

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                andreask Andreas Korneliussen
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated: