db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andreas Korneliussen (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-1696) transaction may sometimes keep lock on a row after moving off the resultset in scrollable updatable resultset
Date Tue, 29 Aug 2006 15:53:23 GMT
     [ http://issues.apache.org/jira/browse/DERBY-1696?page=all ]

Andreas Korneliussen updated DERBY-1696:

    Attachment: DERBY-1696.diff

The attached patch addresses this bug by having the SQL-execution layer use ScanController.reopenScan()
to release the lock.
In the store layer, GenericScanController.reopenScan()  has been modified to release the read-lock
after read, while 
GenericScanController.reopenAfterEndTransaction() now additonally may set the rowLocations
invalidated flag even if the scan_state is SCAN_HOLD_INIT. This is because previously the
scan_state SCAN_HOLD_INIT would (as it was used) guarantee that no RowLocations had been read
from the scan.

Testing: one new test added to ConcurrencyTest. HoldabilityTest had to be modified: if a compress
happens, and there is an open scrollable updatable resultset, no updates will be allowed,
even if no scrolling has happened.

> 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:,,
>            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


View raw message