[ 
https://issues.apache.org/jira/browse/DERBY-1696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mike Matrigali updated DERBY-1696:
----------------------------------

    Labels: derby_triage10_5_2 derby_triage10_9  (was: derby_triage10_5_2)

derby 10.9 triage.  
                
> 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
>              Labels: derby_triage10_5_2, derby_triage10_9
>         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, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to