DBMS Menu

Implementation of Atomicity and Durability in DBMS



Implementation Atomicity

  • When a transaction starts, changes are not immediately written to the original data pages. Instead, new copies of the data pages are created and modified. The original data remains untouched.
  • If the transaction fails or needs to be aborted for some reason, the DBMS simply discards the new pages. Since the original data hasn't been altered, atomicity is maintained. No changes from the failed transaction are visible.

Implementation Durability

  • Once a transaction is completed successfully, the directory that was pointing to the original pages is updated to point to the modified pages. This switch can be done atomically, ensuring durability.
  • After the switch, the new pages effectively become the current data, while the old pages can be discarded or archived.
  • Because the actual switching of the pointers is a very fast operation, committing a transaction can be done quickly, ensuring that once a transaction is declared complete, its changes are durable.

Shadow Database scheme

The Shadow Database scheme is a technique used for ensuring atomicity and durability in a database system, two of the ACID properties. The core idea is to keep a shadow copy of the database and make changes to a separate copy. Once the transaction is complete and it's time to commit, the system switches to the new copy, effectively making it the current database. This allows for easy recovery and ensures data integrity even in the case of system failures.

Working Principle of Shadow Database

  • Initial State: Initially, the database is in a consistent state. Let's call this the "Shadow" database.
  • Transaction Execution: When transactions are executed, they are not applied directly to the shadow database. Instead, they are applied to a separate copy of the database.
  • Commit: After a transaction is completed successfully, the system makes the separate copy the new shadow database.
  • Rollback: If a transaction cannot be completed successfully, the system discards the separate copy, effectively rolling back all changes.
  • System Failure: If a system failure occurs in the middle of a transaction, the original shadow database remains untouched and in a consistent state.

Shadow Database scheme Example

Let's consider a simple banking database that has one table named `Account` with two fields: `AccountID` and `Balance`.

Shadow Database - Version 1


| AccountID | Balance |
|-----------|---------|
| 1         | 1000    |
| 2         | 2000    |

1. Transaction Start: A transaction starts to transfer 200 from AccountID 1 to AccountID 2.

2. Separate Copy: A separate copy of the database is made and the changes are applied to it.

Modified Copy 

    | AccountID | Balance |
    |-----------|---------|
    | 1         | 800     |
    | 2         | 2200    |

3. Commit: The transaction completes successfully. The modified copy becomes the new shadow database.

Shadow Database - Version 2

	
    | AccountID | Balance |
    |-----------|---------|
    | 1         | 800     |
    | 2         | 2200    |

4. System Failure: If the system crashes after this point, the shadow database (Version 2) is already in a consistent state, ensuring durability and atomicity.

Shadow Database scheme Pros

  • Atomicity: All changes are either committed entirely or not at all.
  • Durability: Once changes are committed, they are permanent, even in the case of system failures.

Shadow Database scheme Cons

  • Disk I/O: Requires more disk operations because of the separate copy.
  • Concurrency: More complex to implement in a multi-user environment.

Shadow databases are particularly useful for systems where atomicity and durability are more critical than performance, such as in financial or medical databases.

Next Topic :Concurrent Executions in DBMS