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 lifetime
Date Thu, 17 Nov 2005 17:19:25 GMT


Øystein Grøvlen wrote:
>>>>>>"MM" == Mike Matrigali <mikem_app@sbcglobal.net> writes:
> 
> 
>     MM> Øystein Grøvlen wrote:
> 
>     >>>>>>> "MM" == Mike Matrigali <mikem_app@sbcglobal.net>
writes:
>     >> 
>     >> 
>     MM> It is only stable while some sort of stable table intent lock is held.
>     MM> Rows can move during a compress table operation.
>     >> 
>     >> I understand, when a record is moved to another page, its RecordId
>     >> will change.  Is this the only case where a RecordId will change?  If
>     >> yes, I would think one could solve the problem for insensitive result
>     >> sets by invalidating open result sets when an underlying table is
>     >> compressed.
>     >> 
>     >> Some questions to how compression works:
>     >> - Will RecordIds ever be reused or will the sequence number continue to
>     >> increase?
>     MM> Derby now supports 2 different compression techniques, basically one
>     MM> offline and one online.
> 
>     MM> SYSCS_UTIL.SYSCS_COMPRESS_TABLE() basically copies all rows from one
>     MM> table to another, so recordId's may be reused.  This requires table
>     MM> level locking and so is effectively offline.
> 
> Do not the new version of the table get a new container key?  If yes,
> I would think that recordId's are not reused since container key is
> part of the record id.

That is an interesting point.  I think the correct answer depends on how 
one is using the row location.  Currently the on disk format of the only 
current implementation of a row location is done by HeapRowLocation and 
it only stores a page and record number.  While logically the record id
includes it's container, the current usage only requires the page and
record id.  This was a significant space savings in indexes, but does
restrict all rows in a given index to point to a single container - not
a problem with current implementation.  The in-memory versions of
HeapRowLocation do associate each with a single container for locking.
> 
> 
>     MM> SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE() moves records within the
>     MM> same table, and will not reuse RecordId's, but a given record can
>     MM> definitely change RecordId.  This requires row locks
>     MM> for purged/moved rows for most of it's work.  Giving back space to
>     MM> OS requires short time table level lock.
> 
> Good, I was not aware that there was an online version of compress.
> 
>     >> - How do you ensure that the old RecordIds are not encountered
>     >> during recovery?  Does the compression include a checkpoint?
>     MM> Neither really does anything special to stop old recordId's from
>     MM> being encountered during recovery.   With offline redo recovery of
>     MM> old table is basically a drop table so either the table is there
>     MM> and we drop it again, or the table is already dropped and we do
>     MM> nothing.  In online it is the normal case of redo or a record delete
>     MM> or a record purge, in either case redo will either see a version of
>     MM> the page where it can redo the delete or purge or it will see from
>     MM> the version of the page that there is no work to do.
> 


Mime
View raw message