[ http://issues.apache.org/jira/browse/DERBY-1361?page=comments#action_12415365 ]
Andreas Korneliussen commented on DERBY-1361: --------------------------------------------- It seems to me that it is the store layer which has the knowledge on if a cursor has lost its position as a consequence of a commit. After a commit, the scanstate will be SCAN_HOLD_INPROGRESS. The optimization in DERBY-1087 causes IndexRowToBaseRowResultSet (in SQL execution layer) to no longer need to ask its source resultset for the current row (and thereby doing extra qualification ). Since it does not ask its source resultset, the source resultset no longer access the store layer and gets the exception that the cursor is not on a row. I would propose to fix this by letting IndexRowToBaseRowResultSet call a new method (isCurrentPositionValid()) on its source resultset. The source resultset (i.e TableScanResultSet) may implement this by calling a new method in store's ScanController to check that the position is valid. In terms of internal interface changes, this means that if I follow the proposal, these two interfaces will be extended with a new method: org.apache.derby.iapi.sql.execute.NoPutResultSet#isCurrentPositionValid() <- allows resultsets to call their source resultsets for this info org.apache.derby.iapi.store.access.ScanController#isCurrentPositionValid() <- allows resultsets which access the ScanControllers to get this info from store layer An alternative fix is to continue calling source.getCurrentRow(), however that will mean that the row gets requalified before the update (-> reintroduces the problems of DERBY-1087). Please let me know if anyone has better aproaches of solving this issue. > positioned updates and deletes allowed after a commit without repositioning > the cursor - if the table is indexed on the columns selected > ---------------------------------------------------------------------------------------------------------------------------------------- > > Key: DERBY-1361 > URL: http://issues.apache.org/jira/browse/DERBY-1361 > Project: Derby > Type: Bug > Components: JDBC > Versions: 10.2.0.0 > Environment: Java 1.4 > Reporter: Andreas Korneliussen > Assignee: Andreas Korneliussen > > After a commit, the cursor should be positioned before the next row (not on a > row). However in Derby 10.2, I now see the following behavior if the table > has an index on the selected columns: > ij> create table t (id int primary key); > ij> commit; > ij> insert into t values 1,2,3,4,5,6,7,8,9; > 9 rows inserted/updated/deleted > ij> commit; > ij> get cursor c1 as 'select * from t for update'; > ij> next c1; > ID > ----------- > 1 > ij> commit; > ij> update t set id=id+1000 where current of c1; > 1 row inserted/updated/deleted > ij> commit; > ij> update t set id=id+1000 where current of c1; > 1 row inserted/updated/deleted > ij> > The expected behavior is that the UPDATE .. WHERE CURRENT OF fails with: > ERROR 24000: Invalid cursor state - no current row. > The problem applies to both scrollable and forward-only updatable cursors. > Note: If the table is created *without* the index, I do see the expected > behavior. > I am marking this as a regression, since this issue is not reproducible on > older, released versions of derby (I have tested with 10.1.2.1). -- 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
