ACID and BASE properties, Isolation Levels, Transactions - tarunchhabra/parakalo GitHub Wiki

ACID

https://vladmihalcea.com/a-beginners-guide-to-acid-and-database-transactions/

A transaction is a collection of read/write operations succeeding only if all contained operations succeed.

Inherently a transaction is characterized by four properties (commonly referred as ACID):

Atomicity

Consistency

Isolation- Isolation brings us the benefit of hiding uncommitted state changes from the outside world, as failing transactions shouldn’t ever corrupt the state of the system. Isolation is achieved through concurrency control using pessimistic or optimistic locking mechanisms.

Durability- A successful transaction must permanently change the state of a system, and before ending it, the state changes are recorded in a persisted transaction log

In a relational database, every SQL statement must execute in the scope of a transaction.

For messaging systems like JMS, transactions are not mandatory. That’s why we have non-transacted acknowledgement modes.

These are the guarantees which we should expect from a transaction. But, a transaction doesn't need to provide all of them.

From a database perspective, the atomicity is a fixed property, but everything else may be traded off for performance/scalability reasons.

If the database system is composed of multiple nodes, then distributed system consistency (C in CAP Theorem not C in ACID) mandates that all changes be propagated to all nodes (multi-master replication). If slaves nodes are updated asynchronously then we break the consistency rule, the system becoming “eventually consistent“.

most database management systems choose (by default) to relax correctness guarantees to achieve better concurrency.

most often durability is better off untouched.

For Isolation concurrency control is achieved through locking. Locking increases the serializable portion of the executed code, affecting parallelization.

The SQL standard defines four Isolation levels:

READ_UNCOMMITTED

READ_COMMITTED

REPEATABLE_READ

SERIALIZABLE

All but the SERIALIZABLE level are subject to data anomalies (phenomena) that might occur according to the following pattern:

Phenomena : DIRTY READ NON-REPEATABLE READ PHANTOM READ (Read from Vlad's link)

https://www.baeldung.com/spring-transactional-propagation-isolation

Dirty Read- A dirty read happens when a transaction is allowed to read uncommitted changes of some other running transaction. This happens because there is no locking preventing it.

Non-repeatable read- A non-repeatable read manifests when consecutive reads yield different results due to a concurring transaction that has just updated the record we’re reading. This is undesirable since we end up using stale data. This is prevented by holding a shared lock (read lock) on the read record for the whole duration of the current transaction.

Phantom read-

https://www.baeldung.com/spring-transactional-propagation-isolation

Default Isolation Levels Even if the SQL standard mandates the use of the SERIALIZABLE isolation level, most database management systems use a different default level.

DATABASE DEFAULT ISOLATION LEVEL Oracle READ_COMMITTED MySQL REPEATABLE_READ

Usually, READ COMMITED is the right choice, since not even SERIALIZABLE can protect you from a lost update where the reads/writes happen in different transactions (and web requests). You should take into consideration your enterprise system requirements and set up tests for deciding which isolation level best suits your needs.

Many distributed data systems chose to favor consistency over availability. This gives rise to a new set of guarantees for distributed systems with the acronym as the BASE:

BASE stands for Basically-available, Soft-state, and Eventual consistency

Basically-Available: This guarantee favors availability over consistency as per the CAP theorem. The data system will produce a response to a request, even though the response can be stale.

Soft-state: This refers to the fact that the state of the system can change over time even without any input being received. Hence, the system always remains in a soft state moving towards eventual consistency.

Eventual consistency: This is a guarantee that the system will eventually become consistent once it stops receiving any input. The data changes will eventually propagate to all nodes and all nodes will have the same view of data.

BASE is diametrically opposite to ACID in terms of the consistency model they propose. While ACID enforces consistency at the end of every transaction, BASE accepts that the consistency may be in a state of flux at the end of the transaction.

This relaxation in strong consistency requirements allows for a distributed data system to achieve high availability.

However, it starts to get complicated when we talk about distributed transactions. Since there are multiple databases or resources involved here, a database can't manage such a transaction exclusively. What we need here is a transaction coordinator and individual resources like a database to cooperate in the transaction.

Two-phase Commit

Prepare Phase: This phase consists of the transaction coordinator asking all participants to prepare for commit, the individual resource manager can reply affirmatively or negatively. Commit Phase: This phase involves the transaction coordinator asking all participants to either commit or rollback based on individual responses in the previous phase.

Saga Interaction Pattern

Distributed Transactions in Java

Java Transaction API (JTA) is a Java Enterprise Edition API developed under the Java Community Process. It enables Java applications and application servers to perform distributed transactions across XA resources. JTA is modeled around XA architecture, leveraging two-phase commit.

JTA specifies standard Java interfaces between a transaction manager and the other parties in a distributed transaction:

Let's understand some of the key interfaces highlighted above:

TransactionManager: An interface which allows an application server to demarcate and control transactions UserTransaction: This interface allows an application program to demarcate and control transactions explicitly XAResource: The purpose of this interface is to allow a transaction manager to work with resource managers for XA-compliant resources

Transaction Intro

https://www.baeldung.com/transactions-intro

JTA transactions (declarative and programmative)

https://www.baeldung.com/jee-jta

Spring Transactions Using Declarative way

https://www.baeldung.com/transaction-configuration-with-jpa-and-spring

Transactional Annotations: Spring vs. JTA

https://www.baeldung.com/spring-vs-jta-transactional

Programmatic Transaction Management in Spring

https://www.baeldung.com/spring-programmatic-transaction-management

Transaction Propagation and Isolation in Spring @Transactional

https://www.baeldung.com/spring-transactional-propagation-isolation