Long transactions in an RDBMS
2. Architecture
WM provides a long-transaction framework built on a multi-version system. It uses a series of short
transactions and multiple versions of data to complete a long transaction. WM has a rich set of features
including versioning of database rows using copy-on-write scheme, version trees of arbitrary depth and
fan-out, hierarchical multi-user long transactions, long-transaction locks, conflict detection and resolution,
privilege management, and ability for partial/complete refresh, publish and rollback (long transaction
operations). WM also supports RDBMS features such as referential and unique constraints, DML
triggers, import/export of versioned data, data model evolution, replication, virtual private databases, and
support for direct loading. Figure 1 shows a high-level view of WM architecture.
Figure 1: WM Architecture
A table T is enabled to participate in long transactions by transforming it into a versioned relational data
source (VRDS). This process replaces T with a view over a set of tables that contain data from T and
some additional versioning information. The view filters data based on the current point in the version
hierarchy. This version view is formally defined as follows:
Version View (S, V) for a VRDS S from a version V is the set of the most recent rows that are in the
ancestry of the version V; that is, it is the set of rows from the VRDS S as seen from version V.
This is similar to other long transaction systems that implement versioning by augmenting the primary
key with a version identifier.
Once a collection of tables in a database has been version-enabled, users can start a Long Transaction by
creating a workspace. A workspace is a logical work area for a set of versions. WM contains a single
system-wide version tree; the version tree evolves by explicit version creation operations. Users can set
their working workspace and execute regular SQL statements against a VRDS without any syntax
changes. Changes to versioned objects are made in the latest version of the users’ working workspace.
Figure 2 shows a workspace hierarchy with the underlying version tree:
Figure 2: Workspace Hierarchy
