[ http://issues.apache.org/jira/browse/DERBY-1799?page=all ]
Fernanda Pizzorno updated DERBY-1799:
-------------------------------------
Attachment: derby-1799.diff
derby-1799.stat
The attached patch (derby-1799.diff) implements a similar mechanism for
BTreeScan to the positionAtRowLocation mechanism for HeapScan. As the
ScrollInsensitiveResultSet is populated, the positionKey(key + rowLocation) of
each row is stored in the HashTable. This positionKey is used when scrolling
back to a provious visited row in order to position the BTreeScan, and set
locks on the row if necessary.
The following changes where made to the ScanController interface:
* the method positionAtRowLocation(RowLocation) was changed to
positionAtRow(DataValueDescriptor[]) so that it can be implemented both by
HeapScan and BTreeScan.
* a new method getScanPosition was added. This method is also implemented both
for HeapScan abd BTreeScan. It returns an array of type DataValueDescriptior.
This array has size 1 for HeapScan and contains the RowLocation, and contains
the positionKey (key + RowLocation) for BTreeScan.
The following changes where made to NoPutResultSet interface:
* the method positionScanAtRowLocation(RowLocation) was changed to
positionScanAtRow(DataValueDescriptor[]) so that it can be used both for
RowLocation and positionKey.
* a new method getScanPosition() was added. It returns an array of type
DataValueDescriptior, and therefore can return either a RowLocation or
positionKey depending on whether a HeapScan or BTreeScan is being used.
A new test case was added to ConcurrencyTest. Derbyall is being run with this
patch at the moment, and is has successfully run this patch + the patch for
DERBY-1676. Can someone please review this patch?
> SUR: current row not locked when renavigating to it, in queries with indexes
> ----------------------------------------------------------------------------
>
> Key: DERBY-1799
> URL: http://issues.apache.org/jira/browse/DERBY-1799
> Project: Derby
> Issue Type: Bug
> Components: SQL, Store
> Affects Versions: 10.2.1.0, 10.2.2.0, 10.3.0.0
> Reporter: Andreas Korneliussen
> Assigned To: Fernanda Pizzorno
> Attachments: derby-1799.diff, derby-1799.stat
>
>
> This problem is detected in transactions with isolation level
> read-committed/read-uncommitted.
> We have a table (T) which has a primary key (a), and a query which does
> "select A from T" (an indexed select)
> If the result set is scrollable updatable, we expect the current row to be
> locked with an update lock. This does not seem to happen when repositioning
> to a row which has been already been fetched previously.
> The result is that either the wrong row is locked, or if the result set has
> been on after last position, no row is locked.
> Output from ij:
> ij> get scroll insensitive cursor c1 as 'select a from t for update';
> ij> next c1;
> A
> -----------
> 1
> ij> select * from SYSCS_DIAG.LOCK_TABLE;
> XID |TYPE |MODE|TABLENAME
>
> |LOCKNAME |STATE|TABLETYPE|LOCK&|INDEXNAME
>
>
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> 243 |ROW |U |T
>
> |(1,7) |GRANT|T |1 |NULL
>
>
> 243 |ROW |S |T
>
> |(1,1) |GRANT|T |1 |SQL060901103455010
>
>
> 243 |TABLE|IX |T
>
> |Tablelock |GRANT|T |4 |NULL
>
>
> 3 rows selected
> ij> after last c1;
> No current row
> ij> previous c1;
> A
> -----------
> 3
> ij> select * from SYSCS_DIAG.LOCK_TABLE;
> XID |TYPE |MODE|TABLENAME
>
> |LOCKNAME |STATE|TABLETYPE|LOCK&|INDEXNAME
>
>
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> 243 |TABLE|IX |T
>
> |Tablelock |GRANT|T |4 |NULL
>
>
> 1 row selected
> The last select shows that no row is locked at this point, however we expect
> one row to be locked.
--
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
