<html><body><h2>1/ What is a Database Transaction?</h2><p>Database Transaction is a unit of work, which may include many actions we want to perform with the database system. In a simple word, the transaction represents any change in the database.</p><p>The main purpose of the transaction is:</p><ul><li>Furnish a dependable operational entity capable of facilitating accurate recovery and preserving database consistency during system failure.</li><li>Provide isolation between programs and allow concurrent access to the database.</li></ul><figure class="image image_resized" style="width:35.94%;"><img src="https://api.careers.saigontechnology.com/storage/ck-editor/database-nj4N9CS0ArL3krODuPO9XLykiFwjdWyA6THcbKa6.webp"></figure><h2>2/ Transaction basic and ACID properties</h2><p>Each transaction can have a single operation or a set of operations, which will be performed sequentially. Transaction will wrap this set and use the following pattern to handle SQL execution:</p><ul><li>Begin the transaction.</li><li>Perform a series of data manipulations and/or queries.</li><li>If executed without encountering errors, commit the transaction.</li><li>However, if an error arises during the process, roll back the transaction to its initial state.</li></ul><figure class="image image_resized" style="width:79.12%;"><img src="https://api.careers.saigontechnology.com/storage/ck-editor/Data%203-xzNeMcIxl87PmIk3glBKO8IMWq7llhuzFddFdgJl.webp"></figure><p>By following this pattern, the database can ensure it will provide the ACID properties, which will guarantee data validity despite errors, power failures, and other mishaps.</p><figure class="image image_resized" style="width:81.75%;"><img src="https://api.careers.saigontechnology.com/storage/ck-editor/Data%201-q35H71HVdpwhb2wVlJtpjweXJY9XcYTZNvbRKFkC.webp"></figure><h3>2.1/ Atomicity</h3><p>Atomicity ensures that every transaction is viewed as a singular "unit," ensuring it either completes entirely or fails. In a simple word, it means all or nothing. All the statements (operations) in one transaction must either succeed or fail.</p><p>Consider a monetary transfer from bank account A to account B as an illustration of an atomic transaction. This process entails two distinct operations: withdrawing funds from account A and depositing them into account B. To maintain consistency, we mustn't observe the deduction from account A until we're confident that the corresponding credit has been made to account B. By executing these actions within an atomic transaction, we ensure that the database preserves its integrity. In the event of a failure in either operation, the database remains consistent, preventing any debits or credits from occurring.</p><h3>2.2/ Consistent</h3><p>Consistency guarantees that a transaction transitions the database from one coherent state to another, upholding database invariants. This means that any data modifications adhering to defined rules, such as constraints, cascades, triggers, and their combinations, must maintain validity. In essence, consistency ensures that the database remains in a reliable and predictable state after each transaction, preventing the introduction of invalid or contradictory data.</p><p>CREATE TABLE acid test (A INTEGER, B INTEGER, CHECK (A + B = 100));</p><p>Let’s imagine we have a table with a validation requirement check that A+B = 100.</p><p>Suppose a transaction attempts to deduct 10 from A without updating B. Given that consistency checks occur after each transaction, it's established that A + B equals 100 before the transaction initiation. While the deduction from A may succeed, ensuring atomicity, a subsequent validation check reveals A + B now equals 90, violating the database's rules. Consequently, the entire transaction must be aborted, and the affected rows rolled back to their pre-transaction state to maintain consistency.</p><h3>2.3/ Isolation</h3><p>If our system only executes one transaction by one, everything will be simple. </p><p>Transactions are frequently executed concurrently, necessitating isolation to ensure that concurrent transaction execution results in the same database state as if the transactions were executed sequentially. Isolation serves as the primary objective of concurrency control, guaranteeing that each transaction's effects on the database remain isolated from those of concurrently executing transactions. This isolation prevents interference or inconsistency between transactions, maintaining data integrity and consistency across the database.</p><p>Consider two transactions:</p><ul><li>T1 transfers 10 from A to B.</li><li>T2 transfers 20 from B to A.</li></ul><p>Combined, there are four actions:</p><ul><li>T1 subtracts 10 from A.</li><li>T1 adds 10 to B.</li><li>T2 subtracts 20 from B.</li><li>T2 adds 20 to A.</li></ul><p>If isolation is maintained, these operations are performed in order.</p><p>But if isolation is not maintained, the order of operations might be messed up. One of the possibilities might be:</p><ul><li>T1 subtracts 10 from A.</li><li>T2 subtracts 20 from B.</li><li>T2 adds 20 to A.</li><li>T1 adds 10 to B.</li></ul><p>Consider if T1 fails, but T2 already modified data so it cannot restore data before T1.</p><p>Depending on the isolation level used, the effects of an incomplete transaction might not be visible to other transactions, which we will deep dive into in another section of this article.</p><h3>2.4/ Durability</h3><p>Durability ensures that once a transaction has been successfully committed, its changes are permanently saved and will persist even in the event of a system failure, such as a power outage or crash. This means that once a transaction is confirmed as complete, its effects on the database are guaranteed to endure and will not be lost due to unexpected system failures.</p><h2>3/ Concurrently control mechanism</h2><p>There are many mechanisms to ensure that transactions are executed reliably, maintaining data integrity and allowing multiple transactions to work concurrently while preserving consistency like concurrency control mechanisms, transaction logging, and buffer management. In this section, I will talk about concurrent control mechanisms and how they work.</p><p>Executing transactions sequentially can indeed lead to increased waiting times for other transactions, potentially causing delays in overall execution. To enhance system throughput and efficiency, multiple transactions are executed concurrently. Concurrency control plays a crucial role in database management systems (DBMS) by facilitating simultaneous data manipulation or execution by multiple processes or users without compromising data consistency. By carefully coordinating the concurrent execution of transactions, concurrency control mechanisms ensure that data remains consistent and that transactions do not interfere with each other's operations, thereby optimizing system performance and resource utilization.</p><p>There are some commonly used concurrency control mechanisms: Lock-based concurrency control, Timestamp-based concurrency control, multi-version concurrency control (MVCC), Optimistic concurrency control, Two-phase locking (2PL), and Snapshot isolation. However, the most popular methods to be used to handle concurrent control are Lock-based and MVCC.</p><h3>3.1/ Lock-based</h3><p>This mechanism involves acquiring and releasing locks on database objects such as tables, rows, or columns to control access by concurrent transactions.</p><figure class="image image_resized" style="width:59.61%;"><img src="https://api.careers.saigontechnology.com/storage/ck-editor/Data%204-A26jrksvP0Sx9GnYZ5yFkTwgyMnZ9CMB3iScsqSa.webp"></figure><h4>Type of locks</h4><p>There are different types of locks, including shared locks (read locks) and exclusive locks (write locks), which help prevent conflicting operations:</p><ul><li>Share locks: Allows multiple transactions to read the data item concurrently but prevents any transaction from modifying it until all shared locks are released.</li><li>Exclusive locks: Grants exclusive access to a data item, preventing other transactions from reading or writing it until the lock is released. Once a process acquires a lock on a resource, other processes attempting to acquire the same lock must wait.</li></ul><p>Multiple shared locks can be held simultaneously on a resource. However, if a resource is already locked with a shared lock, another process can't acquire an exclusive lock. Likewise, a process can't acquire a shared lock on a resource that's exclusively locked.</p><h4>Locking problems</h4><p>Although locking is a good way to handle concurrent access, it still has some issues. The three most common problems of locking are:</p><ul><li>Fails to release the lock:  What if the lock fails to release? It will block other transactions and the whole process will be blocked. </li><li>Lock contentions: Some resources may be accessed frequently and multiple transactions could try to acquire locks on these resources at the same time. It leads to subsequent transactions that may encounter delays while waiting for others to complete, resulting in contention for these resources or locks. Imagine you are in a line waiting to check out but there is only 1 counter.</li><li>Locking deadlock: one transaction locks resource A and tries to access the lock on resource B before releasing the lock on the first resource. Simultaneously, another process acquires the lock on resource B while attempting to acquire the lock on resource A. Consequently, both processes remain incomplete until they obtain these locks.</li></ul><h3>3.2/ MVCC</h3><p>An alternative approach to locking is multiversion concurrency control (MVCC), where the database offers each reading transaction the original, unaltered version of data being modified by another active transaction. This enables readers to function without requiring locks, meaning writing transactions doesn't impede reading transactions, and vice versa.</p><h4>Isolation and its problems</h4><p>Remember that the results of the transaction are only visible after a commit to the database happens so what happens when a transaction tries to read a row updated by another transaction? Now our application can handle multiple concurrent actions at the same time, that’s why we will be faced with more complex problems.</p><p>Most of our operations are READ and that’s why most of the problem is about read phenomena.</p><p>We have 4 common read phenomena including:</p><ul><li>Dirty read: Occurs when a transaction reads data modified by another concurrent transaction that has not yet been committed. This can lead to reading inconsistent or erroneous data.</li><li>Nonrepeatable read: This happens when a transaction re-reads data it has previously retrieved and finds that the data has been altered by another transaction that has since been committed. This inconsistency may cause unexpected behaviour.</li><li>Phantom read: Occurs when a transaction re-executes a query with a search condition and finds that the set of rows satisfying the condition has changed due to another transaction being committed in the meantime. This can lead to inconsistencies in query results.</li><li>Serialization anomaly: Refers to a situation where the outcome of executing a group of transactions together is different from the result obtained by executing the same transactions sequentially, one after the other. This inconsistency can violate the desired consistency of the database.</li></ul><h4>Isolation levels</h4><p>With the special problems of reading data when operating with multiple concurrent operations, our database system needs to implement different levels of isolation to solve problems for different use cases.</p><ul><li>Read uncommitted: The lowest isolation level, allowing transactions to read data that hasn't been committed by other transactions. This level doesn't provide isolation, meaning that concurrent transactions may see uncommitted data, potentially leading to inconsistent or incorrect results.</li><li>Read committed: This level allows transactions to read only committed data, preventing dirty reads. However, it doesn't address non-repeatable or phantom reads, as it doesn't lock data during read operations. This is the default isolation level in PostgreSQL.</li><li>Read committed: Transactions at this level lock resources throughout the transaction, preventing other transactions from modifying the same data. While it helps against non-repeatable reads, it may still encounter phantom reads. This level is often used to maintain consistency in data-intensive operations.</li><li>Serializable: The highest level of isolation, emulating serial execution of transactions. All concurrent transactions are treated as if they were executed one after the other, ensuring the highest level of consistency and preventing all concurrency-related anomalies, including non-repeatable reads and phantom reads.</li></ul><figure class="image"><img src="https://api.careers.saigontechnology.com/storage/ck-editor/Data%205-A3N7amL9p17duVPtyxsPcxNXMqBu9QyfKKw9rGc4.webp"></figure><p>Although read uncommitted is the lowest isolation level. Some modern relational database systems like PostgreSQL do not allow it to happen in their system.</p><h2>4/ Demo</h2><p>One of the most valuable characteristics of isolation with developers is Atomicity. When you have to implement an API with a ton of operations including read, write, and update and once an operation fails, others fail and immediately roll back data to the previous state to make sure our database system is consistent. Remember to use database transactions in this case. <br>My simple demo will help you to know how you can use transactions with NodeJS and Prisma: wrap all your operations with Prisma inside the transaction. In my code, assume my application is an application that only allows users to add money to their account with a specific money source: MOMO and VPBANK. My scenario is to create a transaction to add money from the “MOMON” source, which is not allowed in our system. <br>Please check my code for more details.</p><h2>5/ Conclusion</h2><p>In conclusion, transactions are a vital aspect of database management systems, providing a mechanism for ensuring data integrity, consistency, and reliability. By grouping database operations into atomic units, transactions allow for the execution of multiple operations as a single, indivisible entity. This ensures that either all operations succeed and are committed to the database, or none of them are executed, maintaining data integrity and preventing partial updates.</p><p>Choosing a higher isolation level usually comes with a performance trade-off due to increased locking or versioning mechanisms to maintain consistency. The choice of isolation level depends on the specific requirements of your application, balancing the need for data consistency with the desired level of concurrency.</p><p><strong>Resources:</strong></p><ul><li>Demo source code: <a href="https://github.com/saigontechnology/Blog-Resources/tree/main/NodeJS/Khanh.Nguyen/NestJS-Prisma-Transaction"><u>Repo’s link</u></a></li></ul><p><strong>References:  </strong><br><u>- https://medium.com/inspiredbrilliance/what-are-database-locks-1aff9117c290</u> <br><u>- https://www.postgresql.org/docs/current/transaction-iso.html</u></p></body></html>

Let's take a look into one of the most fundamental concepts of databases. This article will show you the main concepts of transaction and  how you can manage transactions in NodeJS with Prisma.

Database Transaction and how to handle it in NodeJS with Prisma

Related articles