Remote Data Access
Transaction File Server (TFS)
RaimaDB utilizes a Transaction File Server (TFS) to access the files that comprise a user database. The TFS is a set of functions called by the RaimaDB runtime library to manage the sharing of database files among one or more runtime library instances. In a multi-user configuration, the TFS functions are wrapped into a server process called TFServer. To connect to a particular TFServer process, the runtime library needs to know the domain name of the computer on which TFServer is running, and the port on which it is listening, for example, “tfs.raima.com:21553”. Standard TCP/IP can be used to make the connection, whether the runtime library and TFServer are on the same computer or different computers (when on the same computer, optimizations are made, and a shared-memory protocol is available by default).
A TFServer should be considered a “database controller” in much the same way as a disk is managed by a disk controller. A TFS is initialized with a root directory in which are stored all files managed by the TFS. If one computer has multiple disk controllers, it is recommended that one TFServer is assigned to each controller. This facilitates parallelism on one computer, especially when multiple CPU cores are also present. RaimaDB comes with three different types of TFS implementations and allows the developer to choose the one that works best for the application space
- Hybrid TFS– A full featured TFS implementation called directly by the runtime library. The hybrid TFS supports multiple threads in a single process.
- Remote TFS– The RPC (Remote Procedure Call) library. When called by the runtime library these functions connect to one or more TFServer processes and call the TFS functions within them. A client/server configuration
- Embedded TFS– “Standalone” TFS functions called directly by the runtime library, but intended only for single-process use (if multiple threads are used, each must be accessing a different database only). To be used for high-throughput batch operations while the database(s) are otherwise offline. Unsafe (but fast) updates are allowed, meaning that database(s) should be backed up before making updates in this configuration.