db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject RowLocation contract from storage engine
Date Fri, 17 Feb 2006 17:48:49 GMT
The following is being driven by some work being done
on insensitive scrollable updateable result sets.  That
thread is: conflict detection strategies

Currently the store provides a RowLocation which is an
access implementation specific unique identifier for a
row.  Specific access implementations may choose to not
provide this access.  Currently the heap access method
provides one, and the btree access method does not.

When creating the conglomerate one can request that
RowLocations be unique throughout the lifetime of the
conglomerate.  Note these RowLocations are unique within
the conglomerate, not across conglomerates.
Store supports this contract with one
exception, the request to truncate pages from the table.
This operation requires an exclusive table lock on
the table.  In current system the reason for not
reusing rowlocations is to avoid false locking, as they
are used as keys to row locking.

The access method must insure that a
RowLocation continues to address the given row, even
with no lock present until a client request is received
to delete the row.  Without this guarantee clients could
not build stable secondary indexes on top of the heap
access method.

Clients of store can delete RowLocations, when doing
this the access method will insure at least a table
level X intent lock and a row level exclusive lock
on the row.  Note
that in a single transaction one cursor can have
the row locked exclusively, but another cursor can
delete the row "out from underneath".  Once a row is
deleted and that delete has been committed, then store
at it's convenience may purge
the row, which means it will be removed completely
from the table and can never be accessed again.

Clients of store can update rows, but RowLocations are

There are a number of client operations that can affect
row locations, by making specific store requests:

o offline compress actually moves all rows from one container
   to another.  Since it is a new container, there is no
   correspondence between old row locations and new.  To store
   this is simply and create and drop container request.  I
   will refer to this as "create/switch container".

o inplace compress moves rows around the container.  It does this
   by deleteing and inserting the rows.  Store will assign new
   row locations to the rows, previous handles to the rows will
   no longer point at the rows.

o inplace compress truncates the end of the table, this phase only
   affects pages with no rows.  The current heap access method does
   not support maintaining unique RowLocations for those pages truncated
   (the current implementation stores info on the pages themselves to
   insure unique future RowLocations).

o I believe a number of the alter table operations also employ the
   "create/switch container"  approach, if there is a need to touch
   all rows in the table.

o I believe that bulk load also uses the "create/switch container"
   in some cases.  bulk load is used by import.

o there may be other usaages of the "create/switch container" in the
   system - I couldn't think of any more off the top of my head.

View raw message