ACID
ACID is the set of database transaction properties—atomicity, consistency, isolation, and durability—that characterize reliable transactional behavior.
100 SQL Server Mistakes and How to Avoid Them
ACID is a set of transaction properties requiring atomicity, consistency, isolation, and durability.
- How it is used
- Frames reliable T-SQL error handling around transactions that must commit or roll back as one unit.
- How deep it goes
- Defines all four properties and relates isolation and durability to locking, logging, isolation levels, and delayed durability.
- Examples
- Uses a failing sales-order procedure, a renamed details table, foreign-key violations, and @@TRANCOUNT to expose an unclosed transaction.
- What you can do after
- Diagnose/debug with @@TRANCOUNT and apply rollback-oriented error handling to failed T-SQL transactions.
Read how 100 SQL Server Mistakes and How to Avoid Them explains ACID →
Building Web APIs with ASP.NET Core
ACID is a set of transaction properties—atomicity, consistency, isolation, and durability—that define reliable behavior for database transactions.
- How it is used
- Frames database transactions as reliable behavior and guides DbContext usage around a unit of work.
- How deep it goes
- Defines the four properties and connects them to DbContext usage, without detailing each property’s internal implementation.
- Examples
- Uses board-game reads and a mechanics-wide rename as concrete transaction scenarios.
- What you can do after
- Apply it via DbContext lifetimes to organize database work within a unit of work.
Read how Building Web APIs with ASP.NET Core explains ACID →
Architecting an Apache Iceberg Lakehouse
The transaction guarantees of atomicity, consistency, isolation, and durability that preserve reliable database state changes.
- How it is used
- Secures shared analytical table updates when multiple jobs, readers, and tools operate concurrently.
- How deep it goes
- Defines all four guarantees and their commit behavior, but stops short of specifying lower-level implementation algorithms.
- Examples
- Uses partial updates, conflicting writes, stale table views, duplicate records, and failure recovery as concrete reliability cases.
- What you can do after
- Operate shared Iceberg tables safely without external locking or coordination.
Read how Architecting an Apache Iceberg Lakehouse explains ACID →
ScyllaDB in Action
ACID is a set of transaction guarantees comprising atomicity, consistency, isolation, and durability.
- How it is used
- Frames transaction guarantees for choosing between relational databases and distributed systems with weaker consistency.
- How deep it goes
- Defines all four guarantees and contrasts their trade-offs with BASE, without detailing transaction implementation internals.
- Examples
- Uses concurrent bank-account operations to demonstrate the practical importance of isolation.
- What you can do after
- Evaluate whether an application needs stronger transactional guarantees than a BASE-oriented distributed database provides.
PostgreSQL Mistakes and How to Avoid Them
ACID is the set of atomicity, consistency, isolation, and durability properties that characterize reliable database transactions.
- How it is used
- Explains why PostgreSQL transaction guarantees do not automatically cover application workflows spanning primaries and read replicas.
- How deep it goes
- Distinguishes per-node ACID safety from distributed transactions and outlines Two-Phase Commit without implementing its full protocol.
- Examples
- Uses a stale account balance, a mistaken bonus, primary alpha, and standby beta to demonstrate a cross-node consistency failure.
- What you can do after
- Diagnose/debug with it by separating database-level ACID guarantees from application-level coordination across replicated nodes.
Read how PostgreSQL Mistakes and How to Avoid Them explains ACID →
Kafka for Architects
ACID is the set of atomicity, consistency, isolation, and durability properties that define conventional transactional behavior.
- How it is used
- Frames transactional guarantees for Kafka read-process-write pipelines and exactly-once event processing.
- How deep it goes
- Defines all four properties and contrasts them with Kafka transactions, stopping short of database implementation internals.
- Examples
- Uses an OrderService writing shipment, billing, and inventory events from each order.
- What you can do after
- Apply Kafka transactions to coordinate exactly-once outputs across a read-process-write pipeline.
Digital Twins in Action
An ACID transaction is a database transaction characterized by atomicity, consistency, isolation, and durability guarantees.
- How it is used
- Guides storage choices for operational records that need reliable transactions, as distinct from high-volume telemetry and less consistency-sensitive analytics.
- How deep it goes
- Defines the four-property acronym and explains storage tradeoffs and a Delta-table implementation, without detailing how each property is enforced.
- Examples
- Uses linked asset work orders and a local Delta-table sensor-data update as concrete cases.
- What you can do after
- Apply it via Delta tables for transactional updates, or evaluate whether relational storage's consistency warrants its latency and scaling costs.
Related concepts
- atomicityhas part · Atomicity is the property that an operation or group of operations takes effect as an indivisible, all-or-nothing unit, without observable partial effects.
- consistencyhas part · Consistency is the property of related data, behavior, outputs, or states agreeing with one another or conforming to defined rules across relevant instances or operations.
- isolationhas part · Isolation is the separation of components, processes, resources, or contexts to limit interaction, interference, or the propagation of effects between them.
- durabilityhas part · Durability is the capacity of data, systems, or other artifacts to persist or remain usable over time despite failures or change.
- BASEcontrasts with · BASE is a distributed-systems consistency model characterized by basic availability, soft state, and eventual consistency.
- database transactionpart of · A database transaction is a logical unit of database operations whose changes are committed together or rolled back as a whole.
These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.