The PACELC theorem is an extension of the CAP theorem. The CAP theorem states that in the case of network partitioning (P) in a distributed system, one has to choose between Availability (A) and Consistency (C).
PACELC extends the CAP theorem by introducing latency (L) as an additional attribute of a distributed system. The theorem states that else (E), even when the system is running normally
in the absence of partitions, one has to choose between latency (L) and consistency (C).
The PACELC theorem was first described by Daniel J. Abadi.
PACELC theorem was developed to address a key limitation of the CAP theorem as it makes no provision for performance or latency.
For example, according to the CAP theorem, a database can be considered Available if a query returns a response after 30 days. Obviously, such latency would be unacceptable for any real-world application.
Transactions
A transaction is a series of database operations that are considered to be a "single unit of work". The operations in a transaction either all succeed, or fail. In this way, the notion of a transaction supports data integrity when part of a system fails. Not all databases choose to support ACID transactions, usually because they are prioritizing other optimizations that are hard or theoretically impossible to implement together.
Usually, relational databases support ACID transactions, and non-relational databases don't (there are exceptions).
States
A transaction in a database can be in one of the following states:
Active
In this state, the transaction is being executed. This is the initial state of every transaction.
Partially Committed
When a transaction executes its final operation, it is said to be in a partially committed state.
Committed
If a transaction executes all its operations successfully, it is said to be committed. All its effects are now permanently established on the database system.
Failed
The transaction is said to be in a failed state if any of the checks made by the database recovery system fails. A failed transaction can no longer proceed further.
Aborted
If any of the checks fail and the transaction has reached a failed state, then the recovery manager rolls back all its write operations on the database to bring the database back to its original state where it was prior to the execution of the transaction. Transactions in this state are aborted.
The database recovery module can select one of the two operations after a transaction aborts:
- Restart the transaction
- Kill the transaction
Terminated
If there isn't any roll-back or the transaction comes from the committed state, then the system is consistent and ready for a new transaction and the old transaction is terminated.