DBMS - Concurrency and Security

What is a transaction
• A database transaction is a logical unit that generally
includes several low-level steps. If one step of the
transaction fails, the whole transaction fails. A database
transaction is used to create, update, or retrieve data.
• Think of a database transaction as a series of
operations performed within a DBMS. The transaction
system ensures that the data in the database always
remains in a reliable and consistent state.
• Commit is an operation that makes all changes
made during the current transaction
permanent. Once a commit operation is
executed, the changes are saved to the
database, and the transaction is considered
complete.
• Rollback is an operation that undoes all
changes made during the current
transaction. If an error occurs or if certain
conditions are not met, a rollback can be
issued to revert the database to its
previous state before the transaction
began.
 Properties of Transactions

The four basic properties of a transaction are ACID.

• Atomicity: Ensures that all operations within the transaction
are completed; if not, the transaction is aborted.
• Consistency: Ensures that the database remains in a consistent
state before and after the transaction.
• Isolation: Ensures that the operations within a transaction are
isolated from other transactions.
• Durability: Ensures that once a transaction is committed, its
changes are permanent, even in the event of a system failure.
 How To Define a Database Transaction

• In SQL the transaction start with BEGIN

TRANSACTION AND END WITH COMMIT
TRANSACTION
 States of a Database Transaction

• In the case of a transactional database, the life cycle of a

transaction can be described by the following four steps:
• The transaction begins: The transactional database
prepares everything required to execute the transaction.
• The queries defined in the transaction are executed: This
is when data manipulation takes place.
• If no errors occur, the transaction is committed: The
transaction ends successfully.
• If an error occurs, it rolls back the transaction: The
transaction ends with failure and any query executed
before it failed is reversed.
 Transaction States
Transaction in DBMS can have the following five
states:
 Key Differences b/w partially committed
and committed
• Permanence of Changes: In the Partially Committed state,
the changes are not yet permanent. They become permanent
only once the transaction reaches the Committed state.
• Visibility of Changes: Changes made during the Partially
Committed state are not visible to other transactions until
the transaction is Committed.
• Transaction Finality: The Partially Committed state is an
intermediate state indicating that the transaction is close to
completion, whereas the Committed state indicates that the
transaction has successfully finished and its effects are now
part of the database.
 Concurrency Control

• Concurrency Control: The process of

managing simultaneous operations on the
database without having them interfere with
one another.
 The Need for Concurrency Control
• A major objective in developing a database is to enable many users to
access shared data concurrently.
• Concurrent access is relatively easy if all users are only reading data,
as there is no way that they can interfere with one another. However,
when two or more users are accessing the database simultaneously
and at least one is updating data, there may be interference that can
result in inconsistencies.
• This objective is similar to the objective of multi-user computer
systems, which allow two or more programs (or transactions) to
execute at the same time.
 Examples of problems caused by
concurrency
• We examine three examples of potential
problems caused by concurrency:
• the lost update problem,
• the uncommitted dependency problem, and
• the inconsistent analysis problem
 Lost Update Problem
• The Lost Update Problem is a concurrency
control issue that occurs in database systems.
• The Lost Update Problem occurs when two or
more transactions read the same data and make
updates to it based on the initial read value,
without knowing about each other's operations.
• As a result, one of the updates may be
overwritten by another, leading to a loss of one
of the updates.
The final balance is incorrectly updated to $1200, whereas it should be $1100 ($1000 -
$100 + $200).
Solution: Using Pessimistic Locking
• With pessimistic locking, a transaction locks
the data it reads to ensure that other
transactions cannot modify it until the lock is
released.
 Uncommitted Dependency Problem
• The Uncommitted Dependency Problem, also
known as the Dirty Read Problem, occurs
when a transaction reads data that has been
written by another transaction that has not
yet committed. If the transaction that made
the initial changes is rolled back, the reading
transaction will have read "dirty"
(inconsistent) data, leading to potential
inconsistencies.
 Example Scenario
• Consider a simple scenario involving two bank
transactions where Transaction A updates the
account balance and Transaction B reads the
balance before Transaction A commits or rolls
back.
• Initial State: The account balance is $1000.
Solution: Using Proper Isolation Levels
• To prevent the uncommitted dependency
problem, proper isolation levels should be
used. The Read Committed isolation level or
higher ensures that a transaction cannot read
data that is not yet committed.
• Step 1 (T1): Transaction A starts.
• Step 2 (T2): Transaction A deducts $100, intending to update the
balance to $900, but this change is not yet committed.
• Step 3 (T3): Transaction B attempts to read the balance, but with
Read Committed isolation, it waits or reads the committed
balance of $1000.
• Step 4 (T4): Transaction A encounters an issue and rolls back the
changes, restoring the balance to $1000.
• Step 5 (T5): Transaction B reads the valid balance of $1000.
• Using the Read Committed isolation level ensures that
Transaction B cannot read the uncommitted balance, thus
preventing the uncommitted dependency problem.
 Inconsistent Analysis Problem
• The Inconsistent Analysis Problem, also known
as the Non-repeatable Read Problem, occurs
when a transaction reads data that is being
modified by another transaction. This leads to
inconsistencies in the analysis because the
data read at different times within the same
transaction does not match.
 Example Scenario
• Consider a simple scenario involving a bank's
financial report generation where a
transaction reads account balances to
calculate the total assets while other
transactions are updating these balances.
 Scenario: Bank Account Balances

Initial State:
Account 1: $1000
Account 2: $2000
Total Assets: $3000
Transactions:
Transaction A: Reads account balances to calculate
the total assets.
Transaction B: Updates the account balance of
Account 2.
1. Step 1 (T1):
1. Transaction A starts and reads the balance of Account 1: $1000.
2. The current balances are $1000 for Account 1 and $2000 for Account 2.
2. Step 2 (T2):
1. Transaction B starts and updates the balance of Account 2 from $2000 to
$2500.
2. Now, the balances are $1000 for Account 1 and $2500 for Account 2.
3. Step 3 (T3):
1. Transaction A continues and reads the balance of Account 2: $2500.
2. It sees the updated balance for Account 2, which was modified by Transaction
B.
4. Step 4 (T4):
1. Transaction A calculates the total assets as $1000 (Account 1) + $2500
(Account 2) = $3500.
2. This is inconsistent because the actual total assets should have been
calculated based on a consistent snapshot of $1000 + $2000 = $3000 before
Transaction B's update.
• The problem here is that Transaction A's read
operations are affected by the committed
changes of Transaction B, leading to a
situation where Transaction A's analysis of the
total assets is based on partially inconsistent
data.
Solution: Using Proper Isolation Levels

• To prevent the inconsistent analysis

problem, use proper isolation levels such
as Repeatable Read. This isolation level
ensures that once a transaction reads
data, it will see the same data throughout
its execution.
• Repeatable Read Isolation Level: This
isolation level ensures that if a transaction
reads a particular data item, any subsequent
reads within the same transaction will return
the same value, even if other transactions
concurrently modify the data. This level
prevents non-repeatable reads and ensures
consistent analysis within a transaction.
1. Step 1 (T1):
1. Transaction A starts and reads the balance of Account 1: $1000.
2. Step 2 (T2):
1. Transaction A reads the balance of Account 2: $2000 (initial read).
3. Step 3 (T3):
1. Transaction B updates the balance of Account 2 from $2000 to $2500.
4. Step 4 (T4):
1. Transaction A attempts to read the balance of Account 2 again.
2. With Repeatable Read isolation level, it will still see the old value of
$2000.
5. Step 5 (T5):
1. Transaction A calculates the total assets as $1000 (Account 1) + $2000
(Account 2) = $3000.
2. This is consistent and reflects the state before Transaction B's update,
ensuring a consistent analysis.
 Deadlock in Databases

• A deadlock in a database occurs when two or

more transactions are waiting for each other
to release locks on resources, creating a cycle
of dependencies that prevents any of the
transactions from proceeding. This situation
results in a standstill where none of the
transactions can move forward.
• Consider two transactions, Transaction A and
Transaction B, that need to update two resources,
Resource 1 and Resource 2.
1. Transaction A locks Resource 1.
2. Transaction B locks Resource 2.
3. Transaction A then tries to lock Resource 2 but
has to wait because Transaction B has already
locked it.
4. Transaction B tries to lock Resource 1 but has to
wait because Transaction A has already locked it.
Step 1 (T1):
Transaction A locks Resource 1.
Step 2 (T2):
Transaction B locks Resource 2.
Step 3 (T3):
Transaction A tries to lock Resource 2 but is blocked
because Resource 2 is already locked by Transaction B.
Step 4 (T4):
Transaction B tries to lock Resource 1 but is blocked
because Resource 1 is already locked by Transaction A.
 Detecting and Resolving Deadlocks

Deadlock Detection
• Databases use various techniques to detect
deadlocks. Once a deadlock is detected, the
system typically chooses one of the
transactions to roll back and releases its locks
to break the cycle.
 Detecting and Resolving Deadlocks

Deadlock Prevention
• To prevent deadlocks, databases can use several strategies:
1. Timeouts:
1. Set a timeout period for a transaction to wait for a lock. If the lock is not
acquired within the timeout period, the transaction is rolled back.
2. Lock Ordering:
1. Ensure that all transactions acquire locks in a predetermined order to
avoid circular wait conditions.
3. Deadlock Detection and Resolution:
1. Periodically check for deadlocks in the system and resolve them by
rolling back one of the transactions involved.
4. Avoiding Long Transactions:
1. Keep transactions short and release locks as soon as possible to
reduce the chance of deadlocks.
 Detecting and Resolving Deadlocks

Deadlock Prevention
• To prevent deadlocks, databases can use several strategies:
1. Timeouts:
1. Set a timeout period for a transaction to wait for a lock. If the lock is not
acquired within the timeout period, the transaction is rolled back.
2. Lock Ordering:
1. Ensure that all transactions acquire locks in a predetermined order to
avoid circular wait conditions.
3. Deadlock Detection and Resolution:
1. Periodically check for deadlocks in the system and resolve them by
rolling back one of the transactions involved.
4. Avoiding Long Transactions:
1. Keep transactions short and release locks as soon as possible to
reduce the chance of deadlocks.
 Database failures
• Database failures can occur due to various
reasons, which can broadly be categorized
into hardware failures, software failures,
human errors, and external factors. Here are
some common reasons for database failures:
 Database failures
• Hardware Failures:
– Disk Crashes: Physical damage to storage devices
can lead to data loss.
– Power Failures: Unexpected power outages can
cause data corruption if transactions are not
properly committed.
– Memory Failures: Issues with the system memory
can corrupt in-memory data.
 Database failures
• Software Failures:
– Bugs in DBMS: Software bugs or vulnerabilities in
the database management system can cause
failures.
– Operating System Crashes: OS-level crashes can
interrupt database operations.
– Application Errors: Faulty application logic
interacting with the database can lead to data
inconsistencies.
 Database failures
• Human Errors:
– Accidental Deletion: Unintended deletion of data
or databases.
– Configuration Errors: Incorrect configuration
settings can lead to database failures.
– Unauthorized Access: Malicious activities by
unauthorized users can cause data loss or
corruption.
 Database failures
• External Factors:
– Natural Disasters: Events such as earthquakes,
floods, or fires can physically damage data centers.
– Cyber Attacks: Hacking, viruses, and ransomware
can corrupt or delete data.
 Database Recovery Ways
• Recovering from a database failure involves
various strategies and techniques to ensure
data integrity and availability. Here are some
common database recovery methods:
 Database Recovery Ways
• Backup and Restore:
• Regular backups of the database are taken,
and in the event of a failure, the database can
be restored to the last known good state using
these backups.
 Database backup Types:

– Full Backup: A complete copy of the entire

database.
– Incremental Backup: Only the changes made since
the last backup are saved.
– Differential Backup: Only the changes made since
the last full backup are saved.