TFS Library Configurations

There is a clear delineation between the runtime library and the TFS. The runtime library understands and manipulates databases, using catalogs that describe the database structure and keeping a local cache of database objects that have been read, created or modified at the request of the application. All of the row and column interpretation is done within the runtime library. The runtime library needs to have a handle to one or more TFSs to do any work.

The TFS is responsible for safely storing the retrieving objects, regardless of the contents of those objects. To the TFS, the objects are opaque sequences of bytes with a given length. When asked to store objects, it does so in a way that is transactionally safe and recoverable. When asked to retrieve objects, it returns the same opaque sequence of bytes. It is like a key/value store, but very fast and transactionally safe. The TFS owns and is co-located with the database files.

This delineation allows for a number of configurations between the runtime library and the TFS.

Physically, the TFS functions may be called directly from within the runtime library in order to operate on database files that are visible to the application process. The TFS functions may also be wrapped into a server process and called through a Remote Procedure Call (RPC) mechanism on the behalf of runtime libraries that are executing within other processes. This distinction between local and remote access to the TFS functions is called "embed" or "remote", and the application programmer may choose between them.

The "embed" configuration is used when an application process with one or more threads uses a database that is not shared with other processes. The "remote" configuration is used when the TFS functions are running within a server process.

Example Design Configurations

There are multiple TFS library configurations included in the product package that support many different application configurations ranging from standalone application usage, to a multiple client applications accessing a centralized database server to a distributed database architecture that may have local and remote database stores.

The sections listed below describe some of the possible system design configurations that are possible with the RaimaDB product using the various TFS libraries included in the RaimaDB product. The best configuration for your application depends upon your application requirements.

Also, note that the different configurations use different TFS libraries when linking the application. The purpose of the multiple library configurations is to reduce the size of the application by excluding functionality that is not needed by the application.

Additional configurations not listed below MAY be supported. Contact Raima Support.