Topic: database transactions

topics > computer science > Group: database

distributed database

concurrent operations
database consistency and reliability
database implementation
log-structured file system
log-structured rollback-recovery
relational database
reliability of distributed systems
temporal database
undoing actions in a UserInterface
updating information in a distributed system
updating information with locking


A transaction is an atomic action that either completes successfully or fails as if it never happened. A database may be temporarily inconsistent within a transaction, while remaining consistent to all other users.

The ACID properties of a transaction are atomicity, consistency, isolation, and durability. Locking, two-phase commit, and logging occur behind the scenes.

Concurrent transactions must be serializable, i.e., equivalent to one transaction happening at a time.

Subtopic: ACID, atomic actions, consistency up

Quote: ACID properties of a transaction: atomicity, consistency, isolation, and durability [»abdaM12_1998]
Quote: an atomic action is serializable, failure atomic, and permanent
Quote: handle temporary database inconsistencies by transactions that transform the database from one consistent state to another [»shavMJ2_1980]
Quote: a consistent database is one that satisfies all stated assertions about its data [»shavMJ2_1980]
Quote: a transaction is either carried out completely or not at all [»smitJM1_1981]
Quote: all actions should be atomic or restartable; i.e., use transactions [»lampBW10_1983]
Quote: remote updates for a transaction may be interleaved with other transactions and updates
Quote: a commit instruction is needed for intrinsic persistence; otherwise program failure may lead to an inconsistent database [»buneP5_1986]

Subtopic: two-phase commit up

Quote: serialization by two-phase locking with a growing phase to acquire locks and an instantaneous shrinking phase to release them [»shriSK7_1993]
Quote: Helix uses two-phase commit and file sets to implement transactions (large-scale atomic actions) [»fridM5_1985]

Subtopic: constraint enforcement up

Quote: constraint enforcement may be too expensive; if so, associate with a block of operations; e.g., database transactions [»tarrP4_1998]

Subtopic: atomic replacement up

Quote: 'careful replacement' by copying current value into working space, writing change, then updating pointers to new value [»maryF_1982]

Subtopic: software transaction up

Quote: simplify concurrent programming by lightweight transactions; use for shared data, object instantiation, exceptions, and blocking [»harrT10_2003]
Quote: lightweight, software transaction without object slots; thread synchronization; requires atomic compare-swap [»harrT10_2003]

Subtopic: other transactions up

Quote: strong-guarantee of exception-safety -- either an operation completes successfully or an exception occurs without changing the program state

Subtopic: open-nested transaction up

Quote: open-nested transactions allows a nested transaction to commit before its parent transaction; e.g., an ID generator commits, allowing other transactions to obtain IDs [»carlBD6_2006]

Subtopic: transactional memory up

Quote: transactional memory prevents a transaction's read set from intersecting another transaction's write set [»carlBD6_2006]
Quote: conditional critical regions in Atomos by watch sets that trip on updates; yields the hardware transactional context until a condition might be true [»carlBD6_2006]

Subtopic: implementation up

Quote: implement transactions in 5 microsec using persistent memory, file cache, and fast, recoverable memory management; no redo log or system calls [»loweDE10_1997]
Quote: a transaction object records a transaction in process; when committed, it becomes a configuration object in the naming structure (history object) [»walpJ6_1988]
Quote: Cedar atomically adds a file to a file server (transfer, new version id, and directory update); implemented with mutual exclusion [»giffDK3_1988]

Subtopic: non-locking transactions up

Quote: SDD-1 does not require that every transaction use global locking to update data [»bernPA5_1978]

Subtopic: distributed transaction up

Quote: distributed systems with backward error recovery use atomic actions or conversations with checkpoints; these are equivalent [»shriSK7_1993]
Quote: a commit (snapshot) in Helix colors all blocks red; must write them to new addresses [»fridM5_1985]

Subtopic: idempotent transactions up

Quote: V reads and writes blocks without a file position; idempotent transactions allows kernel to ignore reply messages [»cherDR4_1984]

Subtopic: serializaiton up

Quote: define sequential consistency of replicated data by a serialization condition; i.e., behavior indistinguishable from a shared-memory system [»afekY1_1993]

Subtopic: replication up

Quote: one-copy serialization on a replicated database is equivalent to some serial execution on a nonreplicated database

Related Topics up

Group: distributed database   (6 topics, 194 quotes)

Topic: backtracking (30 items)
Topic: concurrent operations (22 items)
Topic: database consistency and reliability (15 items)
Topic: database implementation (18 items)
Topic: deadlocks (21 items)
Topic: log-structured file system (11 items)
Topic: log-structured rollback-recovery (13 items)
Topic: relational database (35 items)
Topic: reliability of distributed systems (35 items)
Topic: temporal database (25 items)
Topic: undoing actions in a UserInterface (23 items)
Topic: updating information in a distributed system (50 items)
Topic: updating information with locking
(20 items)

Updated barberCB 6/05
Copyright © 2002-2008 by C. Bradford Barber. All rights reserved.
Thesa is a trademark of C. Bradford Barber.