Transaction: ACID Properties and CAP Theorem

Introduction

In this reading, we will explain some principles on which database transactions are based: ACID Properties (don’t forget to read about Jim GRAY) and CAP Theorem.

Transaction

A transaction is a single logical unit of work that reads, and possibly changes, the contents of a database. Transactions are made up of one or more operations that access data in reading and writing.
In order to maintain consistency in a database, certain properties are followed before and after the transaction. These are called ACID properties.

ACID Properties

• Atomicity: guarantees that all the operations applied to the data in a transaction are made as a single operation. The transaction is considered finalized when all the transactions involved are finalized.

• Consistency: ensures that the operations applied to the data are done by maintaining a consistent state from the beginning to the end of a transaction. A consistent state of the data respects all constraints defined on it.

• Isolation: hides the intermediate states of a transaction from other transactions. This gives concurrent transactions the effect of being serialized. The degree of isolation of a transaction from other transactions is defined by the isolation levels.

• Durability: after the finalization of a transaction, it must be ensured that the other transactions do not cancel the applied operations. This may also require saving the data changes to disk.

CAP Theorem

CAP stands for Consistency, Availability, and Partition Tolerance. The CAP theorem can be used to explain some of the competing requirements in a distributed system with replication.

• Consistency: In a distributed cluster of nodes, each node has the same copy of a replicated data item. Each node returns exactly the most recent and successful written data item. All clients must have the same data view.

• Availability: it means that every read or write request relating to data will be processed correctly or error. Each node must be able to respond in a reasonable amount of time.

• Partition Tolerance: The system can continue to operate even if the network connecting the nodes fails over two or more partitions, where the nodes in each partition can only communicate with each other. With such tolerance, systems can be safely recovered from affected partitions.

However, remember that a distributed data system by default should not compromise the tolerance of the partition anyway. So a distributed data system can’t provide all three of consistency, availability, and partition tolerance simultaneously.

How can we implement transactions with Java and Spring framework, respecting these proprieties? Let’s read this post!

Thanks for reading, stay tuned!

Learn. Grow. Teach.