1. Core Definition and Transaction Lifecycle of ACID Principles
In relational database management systems, acid principles define the four mandatory properties that govern transaction processing: Atomicity, Consistency, Isolation, and Durability. A database transaction is a sequential group of data manipulation statements executed as a single logical operation. Throughout its lifecycle, a transaction transitions through active, partially committed, committed, or aborted states. Enforcing acid principles ensures that database state transitions remain accurate and recoverable across high-concurrency workloads and unexpected system interruptions.
Atomicity requires that every SQL statement within a transaction succeeds collectively. If any statement encounters a constraint violation or runtime error, the database engine aborts the transaction and reverses all prior modifications made during that session. Consistency dictates that a transaction must preserve all predefined database invariants. These invariants include column data types, NOT NULL rules, unique indexes, and foreign key cascading rules. Isolation guarantees that concurrently executing transactions do not expose uncommitted intermediate changes to one another. Durability ensures that once a transaction reaches the committed state, its modifications are written to non-volatile storage and survive power loss or operating system crashes.
Database management systems enforce these four properties through tightly coupled subsystems, including the query parser, lock manager, buffer pool manager, and log manager. Each subsystem validates operational preconditions before permitting state modifications to propagate to persistent storage.
2. Storage Engine Logging Internals for Atomicity and Durability
Database storage engines enforce Atomicity and Durability through Write-Ahead Logging (WAL) and undo log management. Rather than flushing modified data pages directly to disk on every SQL update, the engine modifies data pages in volatile memory buffers first. Before any dirty memory page is written to disk, the storage engine appends a redo log record and an undo log record to persistent storage. The redo log captures the physical or logical changes required to replay the transaction. The undo log records the prior image of the data tuple before the modification occurred.
When a client issues a COMMIT command, the storage engine flushes the redo log buffer to non-volatile disk media using synchronous file system calls. Once the redo log entry is safely persisted on disk, the transaction is durable, even if the modified data pages remain in memory. If a hardware power failure occurs, the database recovery manager scans the WAL during system restart. It replays committed transactions using redo logs (roll-forward recovery) and reverses incomplete transactions using undo logs (rollback recovery). This logging architecture guarantees both rapid commit response times and strict adherence to acid principles.
To optimize recovery time after an unexpected crash, storage engines periodically execute checkpoint operations. Checkpointing flushes dirty memory pages to disk in batches and records the active transaction table state in the write-ahead log. During crash recovery, the engine begins scanning logs from the most recent checkpoint position rather than replaying the entire log history from the beginning.
3. Concurrency Control Anomalies and Isolation Levels
Without proper concurrency control, simultaneous read and write transactions produce data anomalies that violate acid principles. A dirty read occurs when a transaction reads uncommitted modifications made by another active transaction that subsequently rolls back. A non-repeatable read happens when a transaction re-reads a single row and observes different values because another transaction committed an update in the interim. A phantom read occurs when a transaction re-executes a range query and retrieves newly inserted rows added by a concurrent transaction. Write skew arises when two concurrent transactions read overlapping datasets and make disjoint updates that violate a global constraint.
Database engines prevent these anomalies by implementing locking primitives and Multi-Version Concurrency Control (MVCC) across standard isolation levels. Under Read Committed isolation, the engine prevents dirty reads by ensuring queries only access committed tuple versions. Under Repeatable Read isolation, the engine retains a transaction-level snapshot established at the first read operation, eliminating both dirty reads and non-repeatable reads. Serializable isolation represents the strictest level. It utilizes predicate locking or Serializable Snapshot Isolation (SSI) dependency tracking to ensure that concurrent transaction execution produces the exact same state as a serial execution order.
4. OceanBase Transactional Storage Engine and Multi-Tenant ACID Isolation
OceanBase implements acid principles natively within its Log-Structured Merge-tree (LSM-tree) storage engine and distributed transaction manager. Unlike traditional page-based storage engines that suffer from random disk write amplification during transaction flushing, OceanBase separates in-memory active mutations from persistent disk blocks. Active transactional writes and multi-version undo records are inserted into an in-memory MemTable. Simultaneously, redo logs are persisted across a Paxos consensus quorum. When the MemTable reaches capacity, OceanBase compacts and flushes the data sequentially into immutable SSTables on disk, ensuring high-throughput Durability with zero data loss (RPO = 0).
At the concurrency layer, OceanBase retains historical row versions across its MemTable and SSTable hierarchy to support lock-free MVCC reads. Readers and writers do not block each other, enabling the engine to process millions of ACID transactions per second. Furthermore, OceanBase enforces strict multi-tenant architecture. Each database tenant possesses dedicated CPU threads, memory allocators, and independent transaction log streams. A spike in long-running transactions or lock contention within one business tenant never degrades the transactional latency or ACID guarantees of other tenants sharing the cluster. This architecture allows enterprises to consolidate mission-critical transactional databases onto OceanBase with predictable performance and uncompromising data integrity.
