db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Korneliussen <Andreas.Kornelius...@Sun.COM>
Subject Re: RowLocation validation, for holdable SUR
Date Tue, 28 Feb 2006 13:21:27 GMT
Mike Matrigali wrote:
> 
> 
> Andreas Korneliussen wrote:
> 
>> Mike Matrigali wrote:
>>
>>> The SUR should not know anything about the underlying implementation
>>> of the access method getting the row, so having it "read a timestamp"
>>> from page does not work. If the timestamp is not in the rowlocation,
>>> we could add a get a timestamp for row at this rowlocation, but forcing
>>> two trips to the store for every row is a overhead.  Rather than discuss
>>> implementation it would be nice to understand the minimum necessary
>>> services needed to be provided by the access method.  Do the same 
>>> interfaces need to be provided by VTI's?  At least
>>> for your use I think the timestamp need only guarantee to be different
>>> after a truncate from previous version on page.
>>>
>>> Since you are ok with invalidating the SUR in the case of offline 
>>> compress, what about invalidating the SUR in the case of online
>>> compress also?  One way to do this is for the system catalogs to
>>> maintain a table version number, which would be guaranteed to not
>>> change while any sort of table intent lock was present.  Any operation
>>> which either copied rows to another container or truncated the
>>> table would bump the version number.  And holdable cursors would need
>>> to recheck the version number after losing the lock at commit time.
>>>
>>
>> I think I could go for the following solution to invalidate the SUR in 
>> case of online compress:
>> - 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.
>>
>> Note: the ScrollInsensitiveResultSet does not need to know anything 
>> about the sequence number.
>>
>> Andreas
> 
> This sounds like a good direction.
> 
> I was suggesting that the sequence number be maintained in the system
> catalogs and owned by upper layer of the system.  It seems like you are
> proposing the sequence number be owned by store.  If owned by store
> I think I would describe the sequence number something like:
>     An implementation specific long which will be changed to a never
>     previously used number if the table undergoes a change which
>     results in the possibility of a RowLocation which was previously
>     allocated being reused in a container which was built requesting
>     no RowLocation reuse.
> 
> Can you explain at what point, and in which part of the code does the
> system check that the sequence number has changed and then fail the
> SUR?  If only for SUR then there will be some querying from SUR to
> store after every commit.  If only in store then the closing will affect
> existing holdable cursors.
> 

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 "setRowLocation(..)" 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 setRowLocation(..), 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 setRowLocation(..) 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)

Andreas




Mime
View raw message