Skip to content

RDM Architecture

RDMs flexible architecture gives you a variety of configurations. Use RDM in a client/server or peer-to-peer (embedded) application on almost any hardware and software combination. RDM can take full advantage of memory as the main storage medium and persistent data can be stored on-disk.


A Deeper Dive


RDM’s runtime environment is composed as two powerful but well-defined modules:

  1. The Runtime Library – This re-entrant linkable library becomes part of your executable program. It maintains a cache of database objects as it responds to function calls from your program.
  2. The Transactional File Server – This tight, multi-user server interacts with one or more Runtime Libraries concurrently. It manages access to database files. The TFS responds to runtime requests to read objects, to lock objects, or to apply transactional changes.

Runtime Library

As a re-entrant library, RDM fully supports multi-threaded applications. Each thread may open a database and operate on it concurrently with the others.

As a linkable library, RDM operates on data kept in a heap-based cache. Its robust APIs give you full visibility and control over the data. SQL is available through a C-based API, but also accessible through 3rd party tools. Other APIs allow fine-tuning of database operations using a cursor view or an object-oriented view.

Transactional File Server

At its core, the TFS is a library of functions. These functions are called by the runtime library. If the TFS is running in a separate process, its functions are called as RPCs (Remote Procedure Calls) using TCP/IP between computers and shared memory within the same computer.

However, the TFS functions may be linked directly into your application also. This has significant performance benefits and simplicity in operation. It’s faster because the Remote Procedure Calls become Local Procedure Calls (in-process). It’s simpler because everything is running within your program and there is no separate process to start first.


Yes, the Runtime Library and TFS are powerful and well-defined, but they can be configured in several ways. The figures below show just a few.

Multi-Computer Configuration - Amazingly Fast

When multiple computers are involved, they communicate through TCP/IP. If client and server are instead on the same computer, shared memory is used to speed it up.


Multi-Thread Single Computer Configuration - Even Faster

But when the runtime and TFS are in the same process, the inter-process communication is avoided, resulting in even more speed.

Multi-threaded applications are great for handling multiple windows on a screen, each with independent contents.


Single-Thread (exclusive access) - Faster than that!

Simpler, single-user applications have an advantage because there is no concurrent access to the database, hence no locking or waiting.


Single-Thread, In-Memory Database - The Absolute Fastest

Now, load the database from disk into memory and you have database management with all the stops pulled.

The RDM in-memory database option allows for volatile (it goes away when the application stops) and persistent (loaded from disk and saved to disk) databases.

It’s faster because there is no disk latency for reading and no waiting for disk writes during a transaction commit.

These are vulnerable to data loss if the application terminates without saving the data. Sometimes it’s a risk worth taking!