page_title: Raima Database Manager
section_title: Transactional File Server
hierarchical_section_title: Raima Database Manager / Product features / Transactional File Server
caption_attribution_description: English: Raima Database Manager Transactional File Server Operation
context_page_description: Raima Database Manager is an ACID-compliant embedded database management system designed for use in embedded systems applications. RDM has been designed to utilize multi-core computers, networking, and on-disk or in-memory storage management. RDM provides support for multiple application programming interfaces: low-level C API, C++, and SQL. RDM is highly portable and is available on Windows, Linux, Unix and several real-time or embedded operating systems. A source-code license is also available.
  RDM has support for both non-SQL and SQL database design and manipulation capabilities. The non-SQL features are important for the most resource-restricted embedded system environments, where high performance in a very small footprint is the priority. SQL is important in providing a widely known standard database access method in a small enough footprint for most embedded systems environments.
context_section_description: The RDM Transactional File Server (TFS) specializes in the serving and managing of database files on a given medium. The TFS is a set of functions called by the RDM runtime to manage the sharing of database files among one or more runtime library instances. In a normal multi-user configuration, the TFS functions are wrapped into a server process called TFServer. Standard TCP/IP can be used to make the connection, whether the runtime library and TFServer are on the same computer or different computers. However, when on the same computer, a faster, shared-memory protocol is available by default.
  The figure shows that one RDM client runtime may have connections to multiple TFServers, and one TFServer may be used by multiple client runtimes. To the applications using the RDM runtime and the TFServers, the locations of the other processes are invisible, so all processes may be on one computer, or all may be on different computers. This provides opportunities for true distributed processing.
  A TFServer should be considered a “database controller” in much the same way as a disk controller manages a storage device. 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 be assigned to each controller. This facilitates parallelism on one computer, especially when multiple CPU cores are also present.
  A complete application system may have multiple TFServers running on one computer, and multiple computers networked together. Each TFServer will be able to run in parallel with the others, allowing the performance to scale accordingly.
  The TFS functions are used by the RDM runtime, so the programmer has no visibility of the calls made to them. These functions are made available to the runtime library in three forms. For descriptive reasons, we call them TFSr, TFSt and TFSs:
  TFSt: The actual, full-featured TFS functions, called directly  by the runtime library. Supports multiple threads in a single application.
  TFSr: 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.
  TFSs: “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.
caption: Raima Database Manager Transactional File Server Operation
exif: {"Image DateTime": "2011:08:30 23:25:31", "Image Tag 0x0301": "20000/9091", "Image Tag 0x0303": "0", "Image Tag 0x5110": "1", "Image Tag 0x5111": "3780", "Image Tag 0x5112": "3780"}