Our Mission Statement
This is Photoshop's version of Loremer Ipsn gravida nibh vel velit auctoregorie sam alquet.Aenean sollicitudin, lorem quis bibendum auci elit consequat ipsutis sem nibh id elit.
Follow Us
ACID Transactions - VoltDB
page-template-default,page,page-id-6503,mkd-core-1.0,highrise-ver-1.0,,mkd-smooth-page-transitions,mkd-ajax,mkd-grid-1300,mkd-blog-installed,mkd-header-standard,mkd-sticky-header-on-scroll-up,mkd-default-mobile-header,mkd-sticky-up-mobile-header,mkd-dropdown-slide-from-bottom,mkd-dark-header,mkd-header-style-on-scroll,mkd-full-width-wide-menu,mkd-header-standard-in-grid-shadow-disable,mkd-search-dropdown,mkd-side-menu-slide-from-right,wpb-js-composer js-comp-ver-5.1.1,vc_responsive
VoltDB / ACID Transactions

ACID Transactions

Why ACID Transactions are Important

A transaction is a bundling of one or more operations against database state. Databases that offer transactional semantics offer a clear way to start, stop and cancel (or roll back) a set of operations (reads and writes) as a single logical meta-operation.

But transactional semantics do not make a “transaction”. A true transaction must adhere to the ACID properties. ACID transactions offer guarantees that absolve the end user of much of the headache of concurrent access to mutable database state.

What does ACID stand for?

  • Atomicity – All components of a transaction are treated as a single action. All are completed or none are; if one part of a transaction fails, the database’s state is unchanged.
  • Consistency – Transactions must follow the defined rules and restrictions of the database, e.g., constraints, cascades, and triggers. Thus, any data written to the database must be valid, and any transaction that completes will change the state of the database. No transaction will create an invalid data state. Note that this is different from “consistency” as it’s defined in the CAP theorem.
  • Isolation – Fundamental to achieving concurrency control, isolation ensures that the concurrent execution of transactions results in a system state that would be obtained if transactions were executed serially, i.e., one after the other; with isolation, an incomplete transaction cannot affect another incomplete transaction.
  • Durability – Once a transaction is committed, it will persist and will not be undone to accommodate conflicts with other operations. Many argue that this implies the transaction is on disk as well, but this is probably not what the original definition intended. VoltDB is happy either way, as our replication and disk persistence is best-of-breed.

The Argument Against ACID

The argument against ACID is that it costs too much in performance and availability. VoltDB performance is clearly proof by counter-example that ACID can scale performance. Even the relationship between consistency and availability is nuanced. Google has pushed for stronger consistency and ACID across its stack, arguing that the costs of giving up ACID aren’t worth the benefits.

To be specific, giving up ACID means the end user needs to reason about what kinds of additional failures a system might encounter during an operation, then figure out what the right resolutions for those failures are, then write the code to correctly implement detection of the failures and resolution of the failures.

How to Determine if ACID is a Requirement for Your Project

Good questions to ask when determining if ACID is a requirement include:

  • What happens if two operations want to mutate the same data; which wins? What happens to the loser?
  • How long does it take a replica to reflect changes made to a primary?
  • What happens if an operation succeeds on a primary copy of state, but fails on a secondary copy?
  • Between the time I read this data and the time I’m going to write data based on that read, has the original data changed?
  • If my operation has 10 steps, and step 7 fails, do I have to manually undo steps 1 through 6?

Or crucially:

  • What happens if two operations want to mutate the same data at the same time but one fails on a replica on step 7 of 10, and also two other things go wrong?

ACID transactions aren’t a panacea, but where they don’t totally negate one of the above concerns, they make the response much simpler. ACID allows developers to think about a set of changes as a complete unit that will run as if it is the only thing running, and will either succeeded or fail in totality, not piecemeal. The energy used to address all of the concerns above is better spent adding features to the end application, or getting that application into production faster.

In conclusion, ACID transactions allow the application developer to focus on solving problems. At VoltDB, we work every day on distributed systems problems like consensus, coordination and fault resolution. We push forward on state management and managing concurrent access. We do this so you don’t have to – so you can focus on your problem, without worrying about ours. Distributed databases are messy. Through ACID transactions with full serializable isolation, VoltDB users are protected from that messiness.

Learn More

Learn more about the VoltDB in-memory, transactional database.