db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-1799) SUR: current row not locked when renavigating to it, in queries with indexes
Date Tue, 19 Sep 2006 15:52:23 GMT
     [ 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

        

Mime
View raw message