[ http://issues.apache.org/jira/browse/DERBY-1799?page=all ]
Mike Matrigali updated DERBY-1799: ---------------------------------- I don't understand why the new interfaces were added to the access interface. Positiioning by rowlocation in a btree is tricky as the row location for a given row can change anytime a split occurs. Handing that rowlocation out of store and expecting it to be useful in the future seems like a bad direction to take the code. I believe what should be happening is that the scan user should be maintaining the key of the record if they need to position to that place. Then existing interfaces already exist to reopen a scan by key. The postion a scan by RowLocation interfaces were added as an afterthought for heaps, basically to be used when doing probes from an index to heap, where it was known that the rowlocation was protectected by the lock held by the caller on the index row. Could you explain or provide a reference to how, before this change SUR expects to maintain the necessary locks. There may be a bug in locking in the existing reopen logic, I would like to better understand what store interface you are calling when "previous c1" is called and you expect a lock to be held in read uncommitted mode. The positionAtRow interface looks like it provides the same functionality as existing reopenScan() interface. > 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.3.0.0, 10.2.2.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
