db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andreas Korneliussen (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1067) support holdable Scrollable Updatable Resultsets
Date Wed, 01 Mar 2006 10:47:41 GMT
    [ 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


Mime
View raw message