Java Doc for AllocPage.java in  » Database-DBMS » db-derby-10.2 » org » apache » derby » impl » store » raw » data » Java Source Code / Java DocumentationJava Source Code and Java Documentation

This class extends a normal Stored page, with the exception that a hunk of space may be 'borrowed' by the file container to store the file header.

The borrowed space is not visible to the alloc page even though it is present in the page data array. It is accessed directly by the FileContainer. Any change made to the borrowed space is not managed or seen by the allocation page.

Page Format
An allocation page extends a stored page, the on disk format is different from a stored page in that N bytes are 'borrowed' by the container and the page header of an allocation page will be slightly bigger than a normal stored page. This N bytes are stored between the page header and the record space.

The reason why this N bytes can't simply be a row is because it needs to be statically accessible by the container object to avoid a chicken and egg problem of the container object needing to instantiate an alloc page object before it can be objectified, and an alloc page object needing to instantiate a container object before it can be objectified. So this N bytes must be stored outside of the normal record interface yet it must be settable because only the first alloc page has this borrowed space. Other (non-first) alloc page have N == 0.

 <-- borrowed ->
 +----------+-------------+---+---------+-------------------+-------------+--------+
 | FormatId | page header | N | N bytes | alloc extend rows | slot offset |checksum|
 +----------+-------------+---+---------+-------------------+-------------+--------+
 

The maximum space that can be borrowed by the container is 256 bytes.

The allocation page are of the same page size as any other pages in the container. The first allocation page of the FileContainer starts at the first physical byte of the container. Subsequent allocation pages are chained via the nextAllocPageOffset. Each allocation page is expected to manage at least 1000 user pages (for 1K page size) so this chaining may not be a severe performance hit. The logical -> physical mapping of an allocation page is stored in the previous allocation page. The container object will need to maintain this mapping.

The following fields are stored in the page header

See Also:   AllocExtent

Call the extent to update the data structure make the bit map look like contiguous free pages at the end of the extent no longer exist. Similar to preallocate do the operation unlogged, need to force the change to the extent before actually removing the space from the file.

The sequence is: 1) update extent data structure 2) force extent changes to disk 3) truncate pages If the system crashes between 1 and 2 then no changes are on disk. If the system crashes between 2 and 3 then there are extra pages in the file that extent does not know about, this is the same case as preallocation which the code already handes.

Compress the free pages at the end of the range maintained by this allocation page.

Call the extent to update the data structure make the bit map look like contiguous free pages at the end of the extent no longer exist. Similar to preallocate do the operation unlogged, need to force the change to the extent before actually removing the space from the file.

The sequence is: 1) update extent data structure 2) force extent changes to disk 3) truncate pages If the system crashes between 1 and 2 then no changes are on disk. If the system crashes between 2 and 3 then there are extra pages in the file that extent does not know about, this is the same case as preallocation which the code already handes. It will handle any set of pages from 0 to all of the intended pages being truncated. The next allocate looks at actual size of file as does the right thing. exception:
  StandardException - Standard exception policy.

Compress the free pages at the end of the range maintained by this allocation page. All pages being compressed should be FREE. Only pages in the last allocation page can be compressed.

Parameters:
  instant - log address for this operation.
Parameters:
  new_highest_page - The new highest page on this allocation page. The number is the offset of the pagein the array of pages maintained by this allocation page, for instance a value of 0 indicates all page except the first one areto be truncated. If all pages are truncated then the offset is set to -1.
Parameters:
  num_pages_truncated - The number of allocated pages in this allocation page prior to the truncate. Note that all pages from NewHighestPage+1 through newHighestPage+num_pages_truncated should be FREE.
exception:
  StandardException - Standard exception policy.