(and HDB) process creating a DB on disk that can be loaded with a simple

load command. As of now default and partbyenum WDB writedown modes are supported.

The IDB is connected by design and operates in a space between the RDB, WDB and HDB.

As such, the following are some considerations that must be made when creating an IDB:

1. The IDB requires both a WDB and HDB to be operational.

2. On startup, the IDB will automatically attempt to connect itself to a WDB

to facilitate its initialisations steps. These are:

- Attempt to connect to the WBD to retrieve required information:

- WBD location.

- HDB location.

- Current partition.

- Current writedown mode.

- Register itself with the WDB process.

- Loads the WDB and the HDB's sym file.

3. The IDB will have data overlapping with the RDB, so gateways and users should

be mindful when issuing queries.

4. The IDB is designed to fail fast so it doesn't affect surrounding components.

It will self-terminate as soon as an error is encountered, such as when

attempting to load a corrupted DB.

The IDB can be queried just like any other HDB. If writedown mode partbyenum is used it has a useful "maptoint" function which can be used.

The IDB exists on disk and the TorQ gateway will automatically load-balance between

multiple IDB processes linked to the same IDB on disk. This, alongside the implications

of shifting data from an RDB to disk while maintaining availability makes the IDB a

component key to TorQ's scalability.

The IDB can be triggered for an intraday reload, which will automatically detect

any changes to do the least amount of work possible:

1. The sym file will only be reloaded if it has changed size on disk.

2. In partbyenum writedown mode, the IDB will only be reloaded if the number

of partitions has changed.

3. A reload can be forced in cases where the above conditions are not guaranteed

to be met.

The WDB process triggers the intraday reload on all IDBs registered to it.