Better Understanding of ACID Principle In SQL Database

ACID principle in SQL database

ACID  is a set of principles whose acronym is Atomicity, Consistency, isolation and durability. As any other principle, it’s done by the developer or database admin or available feature on the database system of choice (MySQL, Postgres, SQL server). So as a developer or data admin you must know this principle in order to design and develop a database system for your project.

Dealing with database transactions that have many queries in it should be handled following the ACID principle. When a set of queries are executed ACID prevents disaster in your data because something that is partially error in the middle of transaction can lead into data inconsistency. Because the app query expects all the query should be completed with no interruption, sometimes your database depends on other data.

So here’s what ACID principles acronym are:

Atomicity

All queries in a transaction are treated as a single thing, if one query fails, the whole thing shouldn’t change anything.

Atomicity preserves the “completeness” of the business process. Consistency refers to the state of the data both before and after the transaction is executed. A transaction maintains the consistency of the state of the data. In other words, after running a transaction, all data in the database is “correct.”

If you are using MySQL, you must be familiar with

START TRANSACTION

  Query 1

  Query 2

  Query 3

COMMIT

Consistency

If database crash in the middle of transaction, the consistency of the data should remain valid.

When one part of the transaction fails, all of the pending changes are rolled back, leaving the database as it was before you initiated the transaction. For instance, when you delete a customer record, you should also delete all of that customer's records from associated tables (such as invoices and line items). A properly configured database wouldn't let you delete the customer record, if that meant leaving its invoices, and other associated records stranded.

Behind the system, MySQL has two functional operations to handle consistency double write buffer and crash recovery. 

- Double write, when a transaction happens, the queries are not committed yet to the actual MySQL table, rather in buffered memory, only if finished with no crash.

- Crash recovery, MySQL innoDB engine has crash-recovery that will recover failed transactions from transaction log.

Isolation

Lock the data to prevent different transactions modify the same data value at the same time.

Isolation principle will ensure that each transaction in MySQL is invisible to any other transaction that is in progress. MySQL system must allow each transaction to complete and then decide which transaction value is the final data value for the data.

In MySQL InnoDB it implements row-level locking. The row-level locking will lock the data record that’s being modified, so it prevents different queries modifying the same row in a table. MySQL locking does what it says when a transaction is being committed to the database, it locks rows and other threads that modify the same rows can’t access the data.

Durability

Because of the consistency principle,  transactions that are not committed successfully won't be written to the database. However, the durability principle states that when the database is restarted after such a failure(because of resource outage, etc), it should examine those failures in the transaction log, and then it must apply them when the system is back under normal state.

MySQL implements double-buffer, crash recovery to comply with durability principle. The innodb_flush_log_at_trx_commit variable. The sync_binlog variable. The innodb_file_per_table variable. It also provides a feature that interacts with particular hardware configuration. 

ACID principle allows safe, consistent  data to minimize corrupting the data that is not performed by the client when a transaction has such failure. 

When doing transactions that have many queries in it, you should treat the changes to data as a single operation, so if it breaks or partially breaks, those transactions should be canceled or rolled back.

Popular posts from this blog

ERROR 1348 Column Password Is Not Updatable When Updating MySQL Root Password

How To Create Spring Boot Project Using Netbeans

Spring Kafka - How to use ReplyingKafkaTemplate send and reply synchronously