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
