I was wondering if someone could expand on how recids, as used by the application, are mapped to offsets into the store file. I have looked over the code some and it is clear that there are several translation stages, but I am not clear on what they are doing.
Thanks,
-bryan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Recids refer to logical record id's, which are mapped to
physical record id's through special mapping pages. This is done in order to allow compacting of the file without interfering with record id's on the user level compacting not implemented yet) and in order to allow relocation when the record's size changes. Physical record id's are a (page, offset) tuple that point to the place where the record is located. Records can start
anywhere on a page and span any number of pages, with a maximum length of MAXINT.
A file has a one block header with a magic identifier. Following the block are list (head, tail) block pointers for a number of lists: a data list (containing blocks that are used by records), a free list for physical record ids (containing the record id and the size of the record id), and a list that contains logical->physical mappings. All blocks have a header containing a type magic and a (prev, next) tuple, which facilitate reconstruction of the
file in case parts of it are damaged.
At the bottom level, there's a block cache that manages file blocks. In-core images of blocks are preallocated, and a facade object for the block type that directly accesses the block data according to the type is often attached to it. Blocks are retrieved by get(long blockid) operations, and released by release() operations, optionally with a dirty marker to signal the cache that
the block should be written back.
alex
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I was wondering if someone could expand on how recids, as used by the application, are mapped to offsets into the store file. I have looked over the code some and it is clear that there are several translation stages, but I am not clear on what they are doing.
Thanks,
-bryan
From Cees' earlier notes on JDBM:
Recids refer to logical record id's, which are mapped to
physical record id's through special mapping pages. This is done in order to allow compacting of the file without interfering with record id's on the user level compacting not implemented yet) and in order to allow relocation when the record's size changes. Physical record id's are a (page, offset) tuple that point to the place where the record is located. Records can start
anywhere on a page and span any number of pages, with a maximum length of MAXINT.
A file has a one block header with a magic identifier. Following the block are list (head, tail) block pointers for a number of lists: a data list (containing blocks that are used by records), a free list for physical record ids (containing the record id and the size of the record id), and a list that contains logical->physical mappings. All blocks have a header containing a type magic and a (prev, next) tuple, which facilitate reconstruction of the
file in case parts of it are damaged.
At the bottom level, there's a block cache that manages file blocks. In-core images of blocks are preallocated, and a facade object for the block type that directly accesses the block data according to the type is often attached to it. Blocks are retrieved by get(long blockid) operations, and released by release() operations, optionally with a dirty marker to signal the cache that
the block should be written back.
alex