How to Implement Atomicity and Durability in Transactions in DBMS?

Atomicity and durability are ACID properties that ensure the reliability and consistency of transactions in DBMS (database management system). First of all, let’s understand Atomicity and Durability:

Atomicity: By this property, we mean that the entire transaction takes place at once or it does not take place at all. There is no midway. This means that transactions do not occur partially. Either all the changes made by a transaction are committed to the database or none of them are committed.

Durability: By this property, we mean that once a transaction has completed execution its effects persist even in case of system failure. The changes made by the transaction should be stored permanently in the system.

Methods to Implement Atomicity and Durability in DBMS

1. Shadow Copy Scheme

This scheme is based on making copies of the Database. These copies of Databases are also known as Shadow Copies. Suppose there is an active transaction T1. Now, A pointer called Db_pointer is maintained on the disk, which points to the current copy of the Database. The transaction T1 that want to update the Database will first create a complete copy of the Database. All further operations are done on new copy and leave that original copy untouched.

If at any point transaction T1 is aborted, then system delete new copy and the old copy is not affected. It remain untouched.

if Transaction T1 success then OS (Operating System) will make sure that all the pages of new copy of Database are written in the disk. Database system update Db_pointer to point to the new copy of Database. Now, new copy will become current copy of Database. Also old copy of Database will be deleted. Transaction T1 is said to committed only if updated Db-pointer is written on disk.

How Atomicity is Maintained in Shadow Copy Scheme?

If transaction T1 fails any time before Db_pointer is updated, the old content of Database are not affected. Transaction T1 abort can be done by deleting the new copy of Database. So, here either all changes are reflected or none. In this way Atomicity is maintained in this scheme.

How Durability is Maintained in Shadow Copy Scheme?

Let’s suppose, system fails at any time before the updated pointer is written to disk. When system start again, it will try to read the Database pointer (Db_pointer) and thus see the original content of Database. No effects of Transaction T1 will be visible. Transaction T1 is assumed to be successful only when Db_pointer is updated. If system fails after Db_pointer update then before that all the pages of new copy were written on disk. So, When system start again then it will read the new Database copy.

Shadow Copy Scheme

2. Log-Based Recovery Methods

This scheme is based on maintaining the log when our Transaction is executing. Log is the sequence of some records. Log of each Transaction is maintained in a Stable Storage so that in case of any failure it can be recovered from there. If we perform any operation on Database then it will be stored in log. But this process of storing the logs can be done before the actual transaction is done on the database. There are two types of log-based recovery methods, these are :

Deferred DB Modifications

In this method, We ensure Atomicity by recording all the updates or modifications in the log but we deferr the execution of all the write operations until the final action of Transation T1 has been executed or T1 has been committed. Then information in log is used to execute deffered writed when Transaction T1 is completed. If system crashes before completion of T1 or if T1 is aborted then the information in the logs is ignored. If Transaction T1 is completed then the records associated to it in its log file are used to execute the deferred writes. We will perform redo if failure occure duing updation.

Example: Consider a Transaction where we are transferring 50 rupees from A(having Rs 2000) to B(having Rs 3000) then in deferred modification its log will be maintained as

<T1, Start> 
<T1, A, 1950>
<T1, B, 3050>
<T1, Commit>

Immediate DB modifications

In this method, Database modifications to be done to Database while Transaction T1 is in active state. Database modifications written by active Transaction T1 called uncommitted modifications. When any of system crash or failure occure then system uses old value field of the logs to restore the modified values. Update take place only after log records in a stable storage. If system fails before T1 completes or if T1 is aborted then old value field in log table is used to undo T1. If T1 completes and then system crashes then new value field in log table is used to redo T1.

Example: Consider a Transaction where we are transferring 50 rupees from A(having Rs 2000) to B(having Rs 3000) then in deferred modification its log will be maintained as

<T1, Start> 
<T1, A, 2000,  1950>  
<T1, B, 3000, 3050>
<T1, Commit>

Conclusion

In conclusion we can say that Atomicity and Durability are important ACID properties in a database management system (DBMS) to ensure transaction reliability and consistency. The methods we discussed such as Shadow Copy Scheme and Log-based recovery plays important role in implementing Atomicity and Durability in Transactions, ensuring that data remains consistent and recoverable even in case of any system failures.