Binary Datum Repository (hdbBinRepos)

The hdbBinRepos datacron uses block anchoring to limit the size of datum addresses in the index to 4 bytes. In the current unrationalized partition, datum ids are inferred from the file positions of index entries. In the past rationalized partitions, the datum id is explicit in the index entry, so consumes an extra 4 bytes. All index entries state datum size, time and date, so 12 bytes. The respective sizes of current and past index entries are thus 16 and 20. As index entries do not cross block boundaries, the respective density of the indexes are 256 and 204 per 4Kb block.

hdbBinRepos uses a single memory resident map to translate datum id to index block addresses, for all past partitions. Since there are 204 entries per block, this map is small, but there is no alternative to memory residency. As hdbBinRepos is a non-strict datacron there is no update index. The dead index is a serial datacron implemented as a memory resident hdbIdset, backed to delta file.

Data Object Repository (hdbObjRepos)

Wrapper Class Structure

Data object repositories must be able to fully accommodate objects of the native data class, including subclass objects where applicable. With all data class members of type CLASS, there is a choice as to where the subclass objects are stored:- a) As an integral part of the host class object; b) Separately but within the same repository; Or c) Externally in a separate repository. There are pros and cons to each arrangement. (a) offers simple operation but can lead to unweildy objects and unnecessary repetition of data. (b) and (c) avoid this pitfall but have more complex operation. (b) is used where the subclass objects would not be meanigful outside the realm of the host class objects, while (c) is used where the subclass objects are useful in their own right.

To facilitate these options, hdbObjRepos does not store the data objects directly, but acts as a wrapper for its C++ subclasses which do. There are two subclasses: _store_blk which uses persistant media, and _cache_blk which holds data objects in a memory resident indexed chain. All data objects are stored in full, in _store_blk instances. The extent to which the data is also held in _cache_blk instances, depends on what members are deemed to require RAM Primacy. There will be one _store_blk or _store_blk/_cache_blk pair, for the native data class, and another for each case where (b) applies.

hdbObjRepos Datacron Specifics

hdbObjRepos can be configured to store data objects, either in full or on a per member basis, under RAM Primacy. In the case of BOOL/TBOOL members which only use litmus bits, there is no need for _cache_blk EDOs as litmus bits can be held in a delta file backed memory resident idset (the same arrangment used in the dead index). RAM Primacy cannot be used with BINARY and TXTDOC members, but once members other than BOOL, TBOOL, BINARY and TXTDOC are placed under RAM Primacy, a _cache_blk becomes necessary.

By default RAM Primacy is not used to store data objects, either wholly or in part. All data objects are stored in _store_blk and _cache_blk is not deployed. However RAM Primacy is still used, as both the dead and update indexes are serial datacrons. In addition, there will usually be one or more per member indexes. By default, the per member indexes minimize use of RAM, but they also depend on serial datacrons and have the option of placing more of their data under RAM Primacy for better performance.

The main (data object) index can also consume memory. Entries state EDO address, size and write time and date. In the current, and any other yet to be rationalized partitions, data object ids are directly related to the position of index entries in the index file, so are omitted from the entries. In rationalized past partitions the position/id relationship is invalidated by deleted objects, so the id must be supplied in the index entries. If hdbObjRepos is configured to have a RAM Primacy data object index, the time and date is not made memory resident, but the id, address and size is. The cost of the main index is partly mitigated as it eliminates the need for the update index.

The hdbBinRepos datacron uses block anchoring to limit the size of datum addresses in the index to 4 bytes. In the current unrationalized partition, datum ids are inferred from the file positions of index entries. In the past rationalized partitions, the datum id is explicit in the index entry, so consumes an extra 4 bytes. All index entries state datum size, time and date, so 12 bytes. The respective sizes of current and past index entries are thus 16 and 20. As index entries do not cross block boundaries, the respective density of the indexes are 256 and 204 per 4Kb block.

hdbBinRepos uses a single memory resident map to translate datum id to index block addresses, for all past partitions. Since there are 204 entries per block, this map is small, but there is no alternative to memory residency. As hdbBinRepos is a non-strict datacron there is no update index. The dead index is a serial datacron implemented as a memory resident hdbIdset, backed to delta file.