Select Page

Transaction Logging

Gaining a Performance Advantage with the eXtremeDB IMDS and Transaction Logging

eXtremeDB transaction logging adds recoverability to an in-memory database by writing database changes into a transaction log on persistent media. Logging may be set to different levels of transaction durability, allowing system designers to make intelligent trade-offs between performance and risk of unrecoverable transactions.

With the eXtremeDB embedded database version 2.3 and all subsequent versions, McObject increases the options for persistence with the introduction of transaction logging – a process that journals changes made to a database (by transactions), as they are made. With transaction logging enabled, the eXtremeDB runtime captures database changes and writes them to a file known as a transaction log. In the event of a hardware or software failure, the eXtremeDB runtime can recover the database using the log. Logging is performed through periodic checkpoints, where the image of the in-memory database (IMDS) is saved to persistent storage, and all intermediate changes to the database are written to the log files. In this way, the RAM database is made persistent.

Transaction logging does not alter the all-in-memory architecture of eXtremeDB, which retains a performance advantage over disk-based databases. Read performance is unaffected by transaction logging and write performance will far exceed write performance of traditional disk-based databases.

The reason is simple: eXtremeDB transaction logging requires exactly one write to the file system for one database transaction. A disk-based database, however, will perform many writes per transaction (data pages, index pages, transaction log, etc.,) and the larger the transaction and the more indexes that are modified, the more writes that are necessary.

To minimize the performance impact, eXtremeDB equips developers with all the controls they need to tune their applications with persistence and performance in mind. Many eXtremeDB transaction logging features are parameterized so that programmers can invoke the features most appropriate for their application scenario. For example, transaction logging may be turned on or off at runtime and, when turned on, logging may be set to different levels of transaction durability, allowing system designers to make intelligent trade offs between performance and risk for unrecoverable transactions.

Transaction logging also includes McObject’s eXtremeDB data relay technology which facilitates seamless, fine-grained data replication from embedded systems based on eXtremeDB to external systems such as enterprise DBMS, and eXtremeDB’s Persistent Queue of Events. (Use eXtremeDB’s Active Replication Fabric, High Availability or Cluster to replicate between eXtremeDB instances.)

Tests prove a performance advantage of eXtremeDB IMDS and with transaction logging.  Review our white papers for complete details. 


Learn more about eXtremeDB transaction logging persistence options in our online documentation.

Evaluate eXtremeDB free for 60 days

Originally designed as an in-memory database system.

Learn why this matters

Embedded & Real-time Systems

The eXtremeDB in-memory database system was designed specifically for use in resource-constrained, mission-critical and safety-critical embedded systems.

Learn more about eXtremeDB in-memory database for embedded systems


Learn what makes eXtremeDB ideal in real-time systems

High Performance Computing

eXtremeDB in-database analytics offers breakthrough efficiency and can be used with the product’s in-memory database system (IMDS) capability, or independent of it.

Learn about hybrid eXtremeDB for Big Data and Analytics or for Financial systems

Learn more about the IMDS as a powerful, persistent memory caching solution.

Hybrid In-memory and/or Persistent

Combine both database paradigms – in-memory and on-disk – in a single database instance. Specifying one set of data as transient (managed in memory), while choosing persistent storage for other record types, requires a simple database schema declaration.


Learn why starting with an in-memory database makes for a better hybrid system.