db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: RowLocation validation, for holdable SUR
Date Mon, 20 Feb 2006 20:01:16 GMT
Some questions:

o row locations are stored in every index row.  Are you proposing a data 
level upgrade of every row in all databases?
o What is your proposal in the case of soft upgrade (note I believe not
   supporting "holdable" SUR in soft upgrade is an option).
o The hard case is the compress case that removes pages from a file, in
   this case there is no place to store the version number that you
   are relying on (the same problem in the current system why truncte 
can't support non-reusable rowlocations).
o Is it worth the on disk and in memory overhead to every row location 
to support holdable SUR?

I believe one of the operations you are trying to address is when a 
client of store moves a record by deleting and inserting it.  This is
what compress does today.  So if we start with row loc A pointing at
row A, and compress deletes row A and inserts it at row loc B.  In both
the current and new system access to A will return an error, but neither
will "know" that the row has been moved to a new ID.  Is this ok?

If the current system always supported non-reusable row id's, even in
the truncate case do you have what you need?  Again this will not 
prevent clients of store from moving a row by inserting and deleting
it somewhere else.


Andreas Korneliussen wrote:
> 
> Following is a proposal to ensure that a client of store can verify the 
> validity of a RowLocation.  A RowLocation has become invalid if a store 
> operation has caused it to point to another row or to a non-existent 
> position (deleted row or non-existing page/record-id).
> I think we need a mechanism to detect that a RowLocation has become 
> invalid in order to implement *holdable* SUR.
> 
> To do this, I would propose:
> 
> - The RowLocation object should contain a version number for the page.
> 
> - A version number should be stored in the header for a Page
> 
> - Whenever an operation which may invalidate row-locations is executed, 
> the version number for the page is updated. These operations include 
> online/offline compress.
> 
> - When navigating to a RowLocation which has invalid version number, the 
> store may fail (i.e return false)
> 
> The page header for a stored page, currently has a number of fields 
> which are intended for future use, and it seems that it is possible to 
> use these fields without breaking backward compatibility.
> I noticed one of the fields in the header is named "generation" (from 
> StoredPage.java):
> 
>      *  4 bytes integer    generation      generation number of this 
> page(FUTURE USE)
>      *  4 bytes integer    prevGeneration  previous generation of page 
> (FUTURE USE)
> 
> Could I use the generation field for this, or has it been reserved for 
> something else ? Alternatively, I could use one of the other long fields 
> reserved for future use.
> 
> Any comments ?
> 
> Thanks
> 
> --Andreas
> 
> 


Mime
View raw message