[ http://issues.apache.org/jira/browse/DERBY-1067?page=comments#action_12368256 ]
Andreas Korneliussen commented on DERBY-1067: --------------------------------------------- To support holdable SUR, we will invalidate the ResultSet from doing any updates in case of a online compress. This can be done by: - A sequence number is associated with each Container - The sequence number is updated when doing truncate A holdable cursor will need to reopen the controller after a commit, since the controllers get closed at the end of the transaction (in closeForEndTransaction(..)). When reopening a controller, one may check that the sequence number has not been changed since it was initially opened. If it has changed, one can conclude that there has been a online compress, and updates cannot be safely executed, and we may reject the reopen. Any attempt to do update on a non-reopened controller, will fail, and a warning given (cursor operation conflict). This solution does not have the downside of requiring any changes to the page layout, or RowLocation. It also does not have a cost per row. The downside, is that a online compress will invalidate the cursor from doing any update, even for rows which are unaffected of the truncate. - To prevent the solution from having any side-effects on other holdable cursors, we should not generally fail to reopen() a cursor if online compress has run, we should only set a flag in the GenericScanController class. When the GenericScanController class (or one of its subclasses) calls OpenConglom.reopen(), it can read the timestamp from the container, and based on its own scan_state, and previous timestamp read, it can set a flag (oldRowLocationsInvalid). The SUR uses a method currently called positionAtRowLocation(..) which it uses to renavigate the controller. This method could check the oldRowLocationsInvalid flag and return false if the old row locations have become invalidated. So, the setting of the flag, could happen for all holdable cursors, however the call to positionAtRowLocation(..), which is only used by SUR and requires the RowLocation parameter to be a valid row location, is the only call which need to check on that flag, and have logic to fail the operation. If the positionAtRowLocation(..) call fails, the CurrentOfResultSet's will get a null reference to the RowLocation it is going to update. This will cause a positioned update / delete / updateRow() / deleteRow() to fail, and give a warning (Cursor operation conflict) > support holdable Scrollable Updatable Resultsets > ------------------------------------------------ > > Key: DERBY-1067 > URL: http://issues.apache.org/jira/browse/DERBY-1067 > Project: Derby > Type: Sub-task > Reporter: Andreas Korneliussen > Assignee: Andreas Korneliussen > -- 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
