Products Support Documentation Download
Transactions and Locking Overview

RDM implements a transactional locking strategy.

RDM implements a pessimistic transactional locking strategy to prevent simultaneous transactions modifying the same entity at the same time.

The granularity of locks implemented are table locks.

Database Lock

RDM requires that all accesses to the database be contained in transactions. Transaction processing is used to maintain the logical consistency of a database by allowing multiple, related updates to be grouped together and then written to the database as an atomic unit. A read transaction specifies that data read by any statement will be the transactionally consistent version of the data that existed at the start of the transaction. The transaction can only recognize data modifications that were committed before the start of the transaction.

Update Transaction

A write or update transaction, rdm_dbStartUpdate(), allows the developer to take write locks on all tables that will be modified during the transaction. The developer, if needed, can take additional read locks on other tables needed for the transaction up front. Whenever possible, it is recommended to obtain all necessary locks at the beginning to prevent deadlock scenarios.

The process wherein the changes are written to the database is called the transaction commit. The commit is a safe update performed by the Transactional File Server (TFS).

When a write lock is granted, other read and write transactions will be denied access to the write-locked tables.

Read Transaction

A read transaction, rdm_dbStartRead(), requests read-locks on tables that will only be read during the transaction. Again, requesting read-locks for all tables needing access is recommended to avoid deadlocks.

When a read lock is granted, write lock requests to those read-locked tables will be denied access while other read lock requests to the same tables will succeed. Any number of users may hold read locks on the same data.

Transaction Nesting

A nested transaction is a database transaction that is started by an instruction within the scope of an already started transaction. Nested transactions are implemented differently in different databases. However, they have in common that the changes are not made visible to any unrelated transactions until the outermost transaction has committed. This means that a commit in an inner transaction does not necessarily persist updates to the database.

This includes not only updates but reads as well. Transactions can be logically nested which allows for portions of larger transaction to be logically aborted while still allowing the main or root transaction to succeed.

Locks granted by nested transactions are held until the main or root transaction is either committed or rolled back.
Snapshot Transaction

A special read transaction, rdm_dbStartSnapshot(), allows for a snapshot view of the database contents. Modifications to the tables included in the snapshot transaction can proceed but those modifications will not be seen within the current snapshot transaction.

For simultaneous access of a database, locks are required to synchronize reading and writing from the various readers and writers. The RDM lock manger queues lock requests to ensure fair access to the data.

Snapshot transactions cannot be nested. All tables to be included in the snapshot read MUST be requested at the beginning. If modifications to the list of tables to be read is needed, the snapshot transaction must be ended and a new snapshot transaction started.