Introduction
The Master table is the storage for LDAP entries. This is where we store a serialized version of each entry added by all the LDAP users.. Every other tables are indexes used to retrieve easily entries from this master table.
This table is absolutely critical if we want to rebuild the full database, if we have lost some index. However, it requires some dedicated tool to do so, as we don't store each entry's DN into the serialized entry : we only store the entry's RDN and it's parent's ID.
But basically, with only the MasterTable, plus a list of indexes to build, we can rebuild the full database.
Let's now see what's the MasterTable made of.
MasterTable Interface
Somewhere in a partition based on two column data structures (i.e. BTree)a hierarchical data structure, we need to store entry objects. This table will contain the entry objects with all yje attributes and values as the user provided them during add and modify operations. The server may insert additional attributes such as operational attributes into these entries, however all the original attributes provided by the user are as they were including the case of their attribute identifiers.
Such a table stores entries with the Tuple a key set to some unique identifier and the value set to a serialized representation of the entry. The identifier must be unique, right now it's a long and is sequential (that means we are somehow 'limited' to 2^64 - 1 entries).
With the new Entry API, entries serialized into such a table don't contain their DN in the serialized entry. This means we have to rebuild it using the RDN index in order stored in the entry and the parentId we also stored into the entry to return the full Entry. The rest of the information in the partition can be derived from this master copytable.
Hence the MasterTable interface extends the Table interface to lookup entries by numeric identifiers. Each entry is stored and manipulated as a Tuple, which is a couple of data : the key and the value, of which the keys are Long identifiers, and Tuple the values are serialized ServerEntry Entry objects.
| Note |
|---|
Using Long as identifier has the advantage of being simple, but the problem is that we have to deal with the sequential aspect : we need to store each new created number on the disk, which leads to an extra disk access when creating an entry. Also this unique number will be local. We think that using the entry UUID instead would be a better idea. It also implies we have a lock on the incremental counter. Adding or deleting entries are therefore costly operations. |
The MasterTable also contains a means to store simple key value pair properties associated with the partition. These many be used to store configuration settings or other bits of information.
The MasterTable also exposes access to a persistent sequence counter used to generate new identifiers when adding new entries to the table (the Entry identifier, a Long).
JDBM MasterTable Implementation
The JDBM based MasterTable implementation, JdbmMasterTable, simply extends a JdbmTable and locks the Tuple keys to use Long objects. A custom Serializer is used to marshal Entry objects to and from this Table. The implementation uses a property for persisting the current value of it's sequencial sequential counter which starts at 1. There is no entry with value 0.
...