Database transaction¶

A bounded database unit of work whose reads and writes commit together or abort together under declared atomicity, consistency, isolation, and durability guarantees.

Version: v2 · 2026-09-19 · History
Domain-specific #: 4042
Domain group: Applied Sciences & Engineering
Origin domain: Computer Science & Software Engineering
Subdomain: Database Systems → Computer Science & Software Engineering

Core Idea¶

A database transaction groups operations into one recoverable state transition and exposes a commit or rollback boundary independent of interleaved work by other transactions. Concurrency control orders or validates conflicting actions, while logging, versioning, or shadow state permits recovery so incomplete work does not become a committed database state. The abstraction is therefore identified by a declared carrier, a transformation or constraint over that carrier, and an invariant that tells an analyst whether the named structure is genuinely present.

How would you explain it like I'm…

The All-or-Nothing Trade

When you trade a toy with a friend, you give yours and they give theirs, both at once. If something goes wrong halfway, you both get your own toys back, so nobody ends up with two toys or none. A database transaction is a group of changes that all happen together, or none of them happen.

All Together or Not at All

A database transaction is a group of changes that a database treats as one single action. For example, moving money from savings to checking means taking it out of one and adding it to the other. The database makes sure either both happen (called committing) or neither happens (called rolling back), even if the computer crashes halfway. It also keeps transactions happening at the same time from mixing each other up. Once a transaction is committed, its changes stick.

Atomic Commit-or-Rollback Unit

A database transaction groups several operations into one unit that either fully happens or doesn't happen at all. It has a clear end: it either commits, making all its changes permanent, or aborts (rolls back), undoing them all. While many transactions run at the same time, concurrency control orders or checks conflicting actions so they don't interfere in ways the chosen isolation level forbids. Recovery tools such as logs or saved versions make sure that if a crash happens mid-transaction, the half-finished work never shows up as a committed state. A bank transfer is the classic example: the debit and the credit must succeed or fail together.

A database transaction groups a sequence of operations into a single recoverable state transition with an explicit termination boundary: commit or rollback. Its effects are made durable on commit and removed on abort, and the boundary holds independently of interleaved work by other transactions, according to a stated isolation model. Concurrency control, for example locking or validation, orders or checks conflicting actions among concurrent transactions. Recovery mechanisms such as logging, multi-versioning or shadow state ensure that incomplete work never becomes a committed database state, even after failures. The defining conditions are a single transaction identity for the operation sequence, one termination boundary, and all-or-nothing durability under the declared isolation semantics. A batch of independent writes without a shared commit boundary, or an operation whose partial effects can persist after failure, is not a transaction in this sense.

Scope of Application¶

Database transaction belongs to database systems and is useful where the analyst can specify the typed database systems carrier, defining objects and relations, parameters, conventions, evidence, boundary cases, and comparison targets, then evaluate the operation sequence has one transaction identity and termination boundary, with effects made durable on commit or removed on abort under the stated isolation model. The scope is broad within that domain but bounded by the need for the operation sequence has one transaction identity and termination boundary, with effects made durable on commit or removed on abort under the stated isolation model. The entry records a descriptive analytical identity; practical use requires the governing domain's evidence, standards, and safety obligations.

Clarity¶

The abstraction clarifies a crowded vocabulary by making the operation sequence has one transaction identity and termination boundary, with effects made durable on commit or removed on abort under the stated isolation model the center of the account. A claim should name the carrier, the governing operation or relation, the applicable assumptions, and the recognition test. A bare label is insufficient because the name Database transaction can be used for a formal identity, an implementation, or a neighboring result unless carrier and convention are stated.

Manages Complexity¶

Without the abstraction, an analyst must reason directly over many local details: the carrier roles, admissibility assumptions, competing conventions, derived invariants, boundary cases, and proof or validation obligations specific to Database transaction. Database transaction compresses them into the roles in the structural signature. That compression permits comparison across instances without erasing the variables that determine validity. It also exposes which details may be varied safely and which are constitutive.

Abstract Reasoning¶

Identify the carrier. State what the elements, states, objects, or observations are: the typed database systems carrier, defining objects and relations, parameters, conventions, evidence, boundary cases, and comparison targets. Reject examples whose alleged carrier belongs to a different problem.
Lock the constitutive rule. Express the operation sequence has one transaction identity and termination boundary, with effects made durable on commit or removed on abort under the stated isolation model independently of one notation or implementation.

Knowledge Transfer¶

Knowledge transfers strongly among subfields of database systems because they reuse the typed database systems carrier, defining objects and relations, parameters, conventions, evidence, boundary cases, and comparison targets, Concurrency control orders or validates conflicting actions, while logging, versioning, or shadow state permits recovery so incomplete work does not become a committed database state., and type the carrier, state every parameter and convention in the definition, test that the operation sequence has one transaction identity and termination boundary, with effects made durable on commit or removed on abort under the stated isolation model, compare the nearest accepted identity, and report counterexamples, uncertainty, and limiting cases.

Relationships to Other Abstractions¶

Current abstraction Database transaction Domain-specific

Parents (1) — outgoing typed relations

Database transaction is a kind of Commitment Prime

What makes it its own entry: the domain-specific identity determined by the operation sequence has one transaction identity and termination boundary, with effects made durable on commit or removed on abort under the stated isolation model.

Hierarchy path (1) — routes to 1 parentless root

Database transaction → is a kind of Commitment → is a kind of Constraint

Neighborhood in Abstraction Space¶

Database transaction sits in a crowded region of the domain-specific corpus (11^th percentile for distinctiveness): several abstractions share nearly its structure, so a description that fits it tends to fit its neighbors too.

Family — Relational Database Theory (13 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-10-25