Group:
distributed database
Topic:
backtracking
Topic:
concurrent operations
Topic:
database consistency and reliability
Topic:
database implementation
Topic:
deadlocks
Topic:
log-structured file system
Topic:
log-structured rollback-recovery
Topic:
relational database
Topic:
reliability of distributed systems
Topic:
temporal database
Topic:
undoing actions in a UserInterface
Topic:
updating information in a distributed system
Topic:
updating information with locking
| |
Summary
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 
| 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
| 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
| Quote: constraint enforcement may be too expensive; if so, associate with a block of operations; e.g., database transactions [»tarrP4_1998]
|
Subtopic: atomic replacement
| Quote: 'careful replacement' by copying current value into working space, writing change, then updating pointers to new value [»maryF_1982]
|
Subtopic: software transaction
| 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
| Quote: strong-guarantee of exception-safety -- either an operation completes successfully or an exception occurs without changing the program state
|
Subtopic: open-nested transaction
| 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
| 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
| 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
| Quote: SDD-1 does not require that every transaction use global locking to update data [»bernPA5_1978]
|
Subtopic: distributed transaction
| 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
| Quote: V reads and writes blocks without a file position; idempotent transactions allows kernel to ignore reply messages [»cherDR4_1984]
|
Subtopic: serializaiton
| Quote: define sequential consistency of replicated data by a serialization condition; i.e., behavior indistinguishable from a shared-memory system [»afekY1_1993]
|
Subtopic: replication
Quote: one-copy serialization on a replicated database is equivalent to some serial execution on a nonreplicated database
[»franMJ9_1997]
|
Related Topics
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)
|
