Transactions and ACID Properties in Database Systems

Definition of Transaction
A transaction is a sequence of one or more operations (such as read, write,
update, or delete) that are executed as a single unit of work on a database. It
represents a single, logical unit of processing in a database management system
(DBMS).

For example, transferring money from one bank account to another might involve
these steps:
1. Read the balance of the source account
2. Deduct the amount from the source account
3. Read the balance of the destination account
4. Add the amount to the destination account
5. Save both updated balances

All these steps together form a single transaction.

ACID Properties
ACID is an acronym that stands for Atomicity, Consistency, Isolation, and
Durability. These properties ensure that database transactions are processed
reliably.
1. Atomicity- Atomicity guarantees that each transaction is treated as a single,
indivisible unit, which either succeeds completely or fails completely.
- If any part of the transaction fails, the entire transaction fails, and the database is
left unchanged.
- If the transaction succeeds, all changes are committed to the database at once.
Example: In a money transfer, if the deduction from the source account succeeds
but the addition to the destination account fails, the entire transaction is rolled
back, leaving both accounts unchanged.

2. Consistency- Consistency ensures that a transaction brings the database from

one valid state to another valid state, maintaining database invariants.
- All rules, constraints, cascades, and triggers must be applied to maintain data
integrity.
- The database should be in a consistent state before and after the transaction.

Example: If a bank account balance must always be positive, a transaction that

would result in a negative balance should be rejected to maintain consistency.

3. Isolation- Isolation ensures that concurrent execution of transactions leaves the

database in the same state that would have been obtained if the transactions
were executed sequentially.
- Each transaction must appear to execute in isolation from other transactions,
even though many transactions may be executing concurrently.
- Isolation is typically achieved through various isolation levels (Read
Uncommitted, Read Committed, Repeatable Read, Serializable) that provide
different trade-offs between consistency and performance.

Example: If two people try to book the last seat on a flight simultaneously,
isolation ensures that only one booking succeeds while the other fails, as if they
had occurred one after the other.
4. Durability- Durability guarantees that once a transaction has been committed,
it will remain committed even in the case of system failure (e.g., power outage or
crash).
- Committed data is saved by the system in a way that even if there's a system
failure and the database restarts, the changes made by committed transactions
will persist.
- This is typically implemented using transaction logs that allow the recreation of
the committed transactions.

Example: After a customer transfers money and receives a confirmation, the

transaction should persist even if the bank's database server crashes immediately
after. When the system comes back online, the transaction should still be
reflected.

Importance of ACID Properties

ACID properties are crucial for maintaining data integrity and reliability in
database systems, especially in scenarios where data accuracy is critical, such as
financial transactions, inventory management, or booking systems. They provide a
framework for ensuring that database operations are processed reliably, even in
the face of errors, system failures, or concurrent access.

Transaction-Processing

1. Transaction-Processing Monitors
These are software systems that manage transactions in distributed
environments. They coordinate communication between clients and servers,
manage resource allocation, and ensure transaction properties (ACID: Atomicity,
Consistency, Isolation, Durability) are maintained across multiple systems.
Transaction-processing (TP) monitors are middleware systems that manage
transactions across multiple resources in a distributed environment. They ensure
that transactions maintain ACID properties across different systems.

Example: A bank's ATM network

- The TP monitor manages transactions between:
- The ATM interface
- The bank's account database
- The cash dispenser
- The transaction log

When a customer withdraws money:

1. The TP monitor starts a transaction
2. It checks the account balance
3. Updates the account balance
4. Instruct the cash dispenser
5. Logs the transaction
6. Commits the transaction if all steps succeed, or rolls back if any step fails

Popular TP monitors: IBM's CICS, Oracle Tuxedo

2. Transactional Workflows
These are sequences of tasks or activities that form a complete business process,
where each step is treated as a transaction. They ensure that complex, multi-step
processes maintain data integrity and consistency, even if interrupted.
Transactional workflows manage complex business processes as a series of
interconnected transactions, ensuring data consistency across multiple steps.

Example: E-commerce Order Processing

1. Customer places an order (Transaction 1)
2. Payment is processed (Transaction 2)
3. Inventory is updated (Transaction 3)
4. Shipping label is generated (Transaction 4)
5. Order is marked as completed (Transaction 5)

Each step is a separate transaction, but the workflow ensures that all steps are
completed successfully or the entire process is rolled back.

3. Main-Memory Databases
These are database management systems that primarily rely on main memory
(RAM) for data storage, as opposed to traditional disk-based systems. They offer
significantly faster data access and processing, making them suitable for
applications requiring high-speed transactions.
Main-memory databases (MMDBs) store data primarily in RAM for faster access
and processing.

Example: Real-time Analytics Platform

- Traditional DB:
Query: "Count users who logged in last hour"
Time: 5 seconds
- MMDB:
Same Query
Time: 0.1 seconds

MMDBs like Redis or MemSQL are often used for caching, session management,
and real-time analytics where speed is crucial.

4. Real-Time Transaction Systems

These systems process transactions with strict timing constraints. They are
designed to complete transactions within specified time limits, crucial for
applications like financial trading, industrial control systems, or
telecommunications.
These systems process transactions with strict timing constraints, crucial for time-
sensitive applications.

Example: Stock Trading System

- Requirement: Execute trades within 10 milliseconds
- Process:
1. Receive trade order (t = 0ms)
2. Validate order (t = 2ms)
3. Check available funds (t = 4ms)
4. Execute trade (t = 7ms)
5. Confirm trade (t = 9ms)
If any step causes the total time to exceed 10ms, the transaction is flagged or
rejected to maintain system integrity.

5. Long-Duration Transactions
These are transactions that run for extended periods, sometimes hours or days.
They pose challenges to traditional transaction management techniques and often
require special handling to maintain system performance and data consistency.
These are transactions that run for extended periods, challenging traditional
transaction management techniques.

Example: Mortgage Application Process

1. Application submission (Day 1)
2. Credit check (Day 2-3)
3. Property appraisal (Day 4-10)
4. Underwriting review (Day 11-15)
5. Final approval and fund disbursement (Day 16)

Challenges:
- Maintaining locks for extended periods is impractical
- Higher risk of conflicts with other transactions
- Need for compensating transactions if a long-running transaction fails

Solution: Use techniques like sagas or compensating transactions to manage these

long-running processes.

6. Transaction Management in Multi-Databases

This involves coordinating transactions across multiple, possibly heterogeneous,
database systems. It requires techniques to maintain global consistency and
manage distributed transactions while respecting the autonomy of individual
databases.
This involves coordinating transactions across multiple, possibly heterogeneous,
database systems.

Example: Travel Booking System

- Flight reservation (Airline database)
- Hotel booking (Hotel chain database)
- Car rental (Car rental company database)
- Payment processing (Payment gateway database)

Challenges:
1. Maintaining global consistency
2. Handling different transaction protocols
3. Dealing with autonomy of individual databases

Solution: Use of a distributed transaction coordinator (like XA protocol) or

implement a two-phase commit protocol to ensure all or none of the operations
across different databases succeed.

# Concurrency Control Mechanisms in Database Systems

In database systems, concurrent access to shared data by multiple transactions is
a common scenario. Concurrency control mechanisms are used to ensure data
integrity and consistency in the face of these concurrent transactions.

Concurrency Control
Concurrency control is the process of managing and coordinating multiple
concurrent transactions to prevent data corruption and ensure the ACID
properties of transactions.

The main goals of concurrency control are:

1. Isolation: Ensuring that the effects of one transaction are not visible to other
transactions until the transaction commits.
2. Consistency: Maintaining database consistency by applying all transaction-
induced changes correctly.
3. Serializable Execution: Ensuring that the final state of the database is the same
as if all transactions had executed in some serial order.

Types of Concurrency Control Mechanisms

1. Locking-based Concurrency Control

Locking is the most common concurrency control mechanism. It works by allowing
a transaction to obtain locks on data items before accessing them, preventing
other transactions from modifying the same data.

Types of locks:
-Shared (Read) Lock: Allows multiple transactions to read the same data item.
Exclusive (Write) Lock: Allows only one transaction to read and write a data item.
Locking protocols:
- **Two-Phase Locking (2PL)**: Transactions first obtain all necessary locks
(growing phase) and then release them (shrinking phase).
- **Strict Two-Phase Locking (Strict 2PL)**: Locks are held until the end of the
transaction.

2. Optimistic Concurrency Control (OCC)

OCC assumes that conflicts between transactions are rare, so it allows
transactions to execute without acquiring locks. Instead, it checks for conflicts at
the time of commit.

The main steps are:

1. **Read Phase**: Transactions read and modify data without acquiring locks.
2. **Validation Phase**: Transactions validate that no conflicts have occurred.
3. **Write Phase**: If validation succeeds, the changes are written to the
database.
Variations:
- **Backward Validation**: Checks for conflicts with previously committed
transactions.
- **Forward Validation**: Checks for conflicts with transactions that are currently
in the validation phase.

3. Timestamping-based Concurrency Control

Timestamping assigns a unique timestamp to each transaction, and uses these
timestamps to determine the serialization order.
The main steps are:
1. Read Operation: If the data item's timestamp is less than the transaction's
timestamp, the read succeeds.
2. Write Operation: If the data item's timestamp is greater than the transaction's
timestamp, the write is rejected (abort).