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.
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.
Good questions to ask when determining if ACID is a requirement include:
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 about the VoltDB in-memory, transactional database.