0% found this document useful (0 votes)
8 views

UNIT-5 notes[1]

The document explains the concept of transactions in databases, detailing their operations, properties (Atomicity, Consistency, Isolation, Durability), and states (Active, Partially Committed, Committed, Failed, Aborted). It also discusses scheduling of transactions, concurrency control, common problems like lost updates and dirty reads, and the use of locks to manage concurrent access to data. Overall, it emphasizes the importance of maintaining database integrity and consistency during transaction processing.

Uploaded by

hema d
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
8 views

UNIT-5 notes[1]

The document explains the concept of transactions in databases, detailing their operations, properties (Atomicity, Consistency, Isolation, Durability), and states (Active, Partially Committed, Committed, Failed, Aborted). It also discusses scheduling of transactions, concurrency control, common problems like lost updates and dirty reads, and the use of locks to manage concurrent access to data. Overall, it emphasizes the importance of maintaining database integrity and consistency during transaction processing.

Uploaded by

hema d
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 22

UNIT -5

1. WHAT IS TRANSACTION?
 The transaction is a set of logically related operation. It contains
a group of tasks.
A transaction is an action or series of actions. It is performed by
a single user to perform operations for accessing the contents of
the database.
 Example: Suppose an employee of bank transfers Rs 800 from
X's account to Y's account. This small transaction contains
several low-level tasks:
X's Account :-
Open_Account(X)
Old_Balance = X.balance
New_Balance = Old_Balance - 800
X.balance = New_Balance
Close_Account(X)
Y's Account :-
Open_Account(Y)
Old_Balance = Y.balance
New_Balance = Old_Balance + 800
Y.balance = New_Balance
Close_Account(Y)

2. OPERATION IN TRANSACTION?
 Read(X): Read operation is used to read the value of X from
the database and stores it in a buffer in main memory.
 Write(X): Write operation is used to write the value back to the
database from the buffer.

 For example:Let's take an example to debit transaction from an


account which consists of following operations:
1. R(X);
2. X = X - 500;
3. W(X);
Let's assume the value of X before starting of the transaction is
4000.
1. he first operation reads X's value from database and stores it in
a buffer.
2. The second operation will decrease the value of X by 500.
So buffer will contain 3500.
3. The third operation will write the buffer's value to the database.
So X's final value will be 3500.
But it may be possible that because of the failure of hardware,
software or power, etc. that transaction may fail before finished all
the operations in the set
 For example: If in the above transaction, the debit transaction
fails after executing operation 2 then X's value will remain 4000
in the database which is not acceptable by the bank.
To solve this problem, we have two important operations:
 Commit: It is used to save the work done permanently.
 Rollback: It is used to undo the work done.
3. Properties of transaction?

Atomicity
o ○ The phrase “all or nothing” describes the first ACID property
i.e. atomicity.
o It states that all operations of the transaction take place at once
if not, the transaction is aborted.
o There is no midway, i.e., the transaction cannot occur partially.
Each transaction is treated as one unit and either run to
completion or is not executed at all.
o Atomicity involves the following two
operations:
o Abort: If a transaction aborts then all the changes
made are not visible.
o Commit: If a transaction commits then all the
changes made are visible.

o Example: Let's assume that following transaction


T consisting of T1 and T2. A consists of Rs 600 and
B consists of Rs 300. Transfer Rs 100 from account
A to account B.
T1 T2

Read(A) Read(B)
A:= A-100 Y:= Y+100
Write(A) Write(B)

After completion of the transaction, A consists of Rs 500 and B


consists of Rs 400.
If the transaction T fails after the completion of transaction T1 but
before completion of transaction T2, then the amount will be
deducted from A but not added to B. This shows the inconsistent
database state. In order to ensure correctness of database state, the
transaction must be executed in entirety.
The mechanism for maintaining atomicity is done by the DBMS
keeping track of the old values of the data on which the write
operation is performed and if the transaction does not complete its
execution, the old values are restored to appear as if the transaction
had never been executed.

Consistency
o The phrase “no violation of integrity constraints” describes the
property of consistency.
o The integrity constraints are maintained so that the database is
consistent before and after the transaction.
o The execution of a transaction will leave a database in either its
prior stable state or a new stable state.
o The consistent property of database states that every
transaction sees a consistent database instance.
o The transaction is used to transform the database from one
consistent state to another consistent state.
For example: The total amount must be maintained before or after
the transaction.
1. Total before T occurs = 600+300=900
2. Total after T occurs= 500+400=900
Therefore, the database is consistent. In the case when T1 is
completed but T2 fails, then inconsistency will occur.
Without a consistent property, money can be credited or debited by
the transaction. It is the responsibility of the application
programmers who code the transaction to maintain the consistency
for individual transactions by enforcing consistency constraints on
the database.

Isolation
o It shows that the data which is used at the time of execution of
a transaction cannot be used by the second transaction until
the first one is completed.
o In isolation, if the transaction T1 is being executed and using
the data item X, then that data item can't be accessed by any
other transaction T2 until the transaction T1 ends.
o The concurrency control subsystem of the DBMS enforced the
isolation property.
For example:
Let X = 500, Y = 500.
Consider two transactions T and T”.
Suppose T has been executed till Read (Y) and then T’’ starts. As a
result, interleaving of operations takes place due to which T’’ reads
the correct value of X but the incorrect value of Y and sum computed
by
T’’: (X+Y = 50, 000+500=50, 500)
is thus not consistent with the sum at end of the transaction:
T: (X+Y = 50, 000 + 450 = 50, 450) .
This results in database inconsistency, due to a loss of 50 units.
Hence, transactions must take place in isolation and changes should
be visible only after they have been made to the main memory.

Durability
o The durability property is used to indicate the performance of
the database's consistent state. It states that the transaction
made the permanent changes.
o They cannot be lost by the erroneous operation of a faulty
transaction or by the system failure. When a transaction is
completed, then the database reaches a state known as the
consistent state. That consistent state cannot be lost, even in
the event of a system's failure.
o The recovery subsystem of the DBMS has the responsibility of
Durability property.
Some important points:

Property Responsibility for maintaining properties

Atomicity Transaction Manager

Consistenc
Application programmer
y

Isolation Concurrency Control Manager

Durability Recovery Manager

4. TRANSACTION STATES?
Active state
o The active state is the first state of every transaction. In this
state, the transaction is being executed.
o For example: Insertion or deletion or updating a record is done
here. But all the records are still not saved to the database.
Partially committed
o In the partially committed state, a transaction executes its final
operation, but the data is still not saved to the database.
o In the total mark calculation example, a final display of the total
marks step is executed in this state.
Committed
A transaction is said to be in a committed state if it executes all its
operations successfully. In this state, all the effects are now
permanently saved on the database system.
Failed state
o If any of the checks made by the database recovery system fails,
then the transaction is said to be in the failed state.
o In the example of total mark calculation, if the database is not
able to fire a query to fetch the marks, then the transaction will
fail to execute.
Aborted
o If any of the checks fail and the transaction has reached a failed
state then the database recovery system will make sure that the
database is in its previous consistent state. If not then it will
abort or roll back the transaction to bring the database into a
consistent state.
o If the transaction fails in the middle of the transaction then
before executing the transaction, all the executed transactions
are rolled back to its consistent state.
o After aborting the transaction, the database recovery module
will select one of the two operations:
o Re-start the transaction
o Kill the transaction
5. Schedule
A series of operation from one transaction to another transaction is
known as schedule. It is used to preserve the order of the operation
in each of the individual transaction.

1. Serial Schedule
The serial schedule is a type of schedule where one transaction is
executed completely before starting another transaction. In the serial
schedule, when the first transaction completes its cycle, then the
next transaction is executed.
2. Non-serial Schedule
o If interleaving of operations is allowed, then there will be non-
serial schedule.
o It contains many possible orders in which the system can
execute the individual operations of the transactions.
o In the given figure (c) and (d), Schedule C and Schedule D are
the non-serial schedules. It has interleaving of operations.
3. Serializable schedule
o The serializability of schedules is used to find non-serial
schedules that allow the transaction to execute concurrently
without interfering with one another.
o It identifies which schedules are correct when executions of the
transaction have interleaving of their operations.
o A non-serial schedule will be serializable if its result is equal to
the result of its transactions executed serially.
 Conflict Serializable: A schedule is called conflict serializable if it
can be transformed into a serial schedule by swapping non-
conflicting operations. Two operations are said to be conflicting
if all conditions satisfy:

 Conflicting Operations:-

 They belong to different transactions


 They operate on the same data item
 At Least one of them is a write operation

For example:-
6. Concurrency Control
Concurrency Control is the management procedure that is required
for controlling concurrent execution of the operations that take place
on a database.
But before knowing about concurrency control, we should know
about concurrent execution.
(OR) Concurrency Control
Concurrency Control is the working concept that is required for
controlling and managing the concurrent execution of database
operations and thus avoiding the inconsistencies in the database.
Thus, for maintaining the concurrency of the database, we have the
concurrency control protocols.

 Concurrent Execution in DBMS


o In a multi-user system, multiple users can access and use the
same database at one time, which is known as the concurrent
execution of the database. It means that the same database is
executed simultaneously on a multi-user system by different
users.
o While working on the database transactions, there occurs the
requirement of using the database by multiple users for
performing different operations, and in that case, concurrent
execution of the database is performed.
o The thing is that the simultaneous execution that is performed
should be done in an interleaved manner, and no operation
should affect the other executing operations, thus maintaining
the consistency of the database. Thus, on making the
concurrent execution of the transaction operations, there occur
several challenging problems that need to be solved.
 Problems with Concurrent Execution
In a database transaction, the two main operations
are READ and WRITE operations. So, there is a need to manage these
two operations in the concurrent execution of the transactions as if
these operations are not performed in an interleaved manner, and
the data may become inconsistent. So, the following problems occur
with the Concurrent Execution of the operations:
Problem 1: Lost Update Problems (W - W Conflict)
The problem occurs when two different database transactions
perform the read/write operations on the same database items in an
interleaved manner (i.e., concurrent execution) that makes the values
of the items incorrect hence making the database inconsistent.
For example:
Consider the below diagram where two transactions TX and TY, are
performed on the same account A where the balance of account A
is $300.
o At time t1, transaction TX reads the value of account A, i.e.,
$300 (only read).
o At time t2, transaction TX deducts $50 from account A that
becomes $250 (only deducted and not updated/write).
o Alternately, at time t3, transaction TY reads the value of account
A that will be $300 only because TX didn't update the value yet.
o At time t4, transaction TY adds $100 to account A that becomes
$400 (only added but not updated/write).
o At time t6, transaction TX writes the value of account A that will
be updated as $250 only, as TY didn't update the value yet.
o Similarly, at time t7, transaction TY writes the values of account
A, so it will write as done at time t4 that will be $400. It means
the value written by TX is lost, i.e., $250 is lost.
Hence data becomes incorrect, and database sets to inconsistent.
 Dirty Read Problems (W-R Conflict)
The dirty read problem occurs when one transaction updates an item
of the database, and somehow the transaction fails, and before the
data gets rollback, the updated database item is accessed by another
transaction. There comes the Read-Write Conflict between both
transactions.
For example:
Consider two transactions TX and TY in the below diagram
performing read/write operations on account A where the available
balance in account A is $300:
o At time t1, transaction TX reads the value of account A, i.e.,
$300.
o At time t2, transaction TX adds $50 to account A that becomes
$350.
o At time t3, transaction TX writes the updated value in account A,
i.e., $350.
o Then at time t4, transaction TY reads account A that will be read
as $350.
o Then at time t5, transaction TX rollbacks due to server problem,
and the value changes back to $300 (as initially).
o But the value for account A remains $350 for transaction TY as
committed, which is the dirty read and therefore known as the
Dirty Read Problem.
 Unrepeatable Read Problem (W-R Conflict)
Also known as Inconsistent Retrievals Problem that occurs when in a
transaction, two different values are read for the same database
item.
For example:
Consider two transactions, TX and TY, performing the read/write
operations on account A, having an available balance = $300.

o At time t1, transaction TX reads the value from account A, i.e.,


$300.
o At time t2, transaction TY reads the value from account A, i.e.,
$300.
o At time t3, transaction TY updates the value of account A by
adding $100 to the available balance, and then it becomes $400.
o At time t4, transaction TY writes the updated value, i.e., $400.
o After that, at time t5, transaction TX reads the available value of
account A, and that will be read as $400.
o It means that within the same transaction TX, it reads two
different values of account A, i.e., $ 300 initially, and after
updation made by transaction TY, it reads $400. It is an
unrepeatable read and is therefore known as the Unrepeatable
read problem.
Thus, in order to maintain consistency in the database and avoid such
problems that take place in concurrent execution, management is
needed, and that is where the concept of Concurrency Control comes
into role.
7. Lock
A Lock is a variable assigned to any data item to keep track
of the status of that data item so that isolation and non-
interference are ensured during concurrent transactions.
Lock-based concurrency control ensures that transactions in
a database can proceed safely without causing conflicts.
1. Shared lock:
o It is also known as a Read-only lock. In a shared lock, the data
item can only read by the transaction.
o It can be shared between the transactions because when the
transaction holds a lock, then it can't update the data on the data
item
o Definition: A shared lock allows multiple transactions to read a
resource (e.g., a database record) simultaneously, but prevents
any transaction from modifying it.
o Purpose: Ensures that data being read is consistent and prevents
simultaneous reads from interfering with each other.
o Example: If Transaction A places a shared lock on a record to
read it, Transaction B can also place a shared lock on the same
record to read it, but neither can modify it until all shared locks
are released.

2. Exclusive lock:
o In the exclusive lock, the data item can be both reads as well as
written by the transaction.
o This lock is exclusive, and in this lock, multiple transactions do
not modify the same data simultaneously.
o Definition: An exclusive lock allows only one transaction to
access a resource for modification and prevents any other
transaction from reading or modifying it.
o Purpose: Ensures data consistency during write operations by
blocking all other transactions from accessing the locked
resource.
o Example: If Transaction A places an exclusive lock on a record
to update it, no other transaction can read or modify that record
until the exclusive lock is released.
For example:
Scenario: *Online Ticket Booking System*
Imagine a movie ticket booking platform where multiple users are
trying to book tickets for the same show at the same time. Each show
has a limited number of seats available.

| ShowID | AvailableSeats |
|------------|-------------------|
| 101 |5 |

With Lock:
The DBMS uses locking to ensure data consistency:

1. *User A* initiates the booking process:


- Acquires an *exclusive lock (X)* on the AvailableSeats column
for Show 101.
- Reads AvailableSeats = 5.
- Updates AvailableSeats = 2 (5 - 3).
- Commits the transaction and releases the lock.

2. *User B* tries to book tickets:


- Attempts to acquire a lock but waits because User A's transaction
is still active.
- After User A's transaction is completed, User B reads the updated
AvailableSeats = 2.
- User B's booking of 4 tickets fails because there are only 2 seats
left.

*Result*: Total seats sold = 3 (consistent with the actual number of


available seats).
NOTE:-
- Locking ensures *data integrity* by preventing multiple users from
updating the same data simultaneously.
- Without locking, race conditions can lead to *inconsistent states*,
such as overselling tickets.
- Proper transaction management (using locks) ensures that critical
sections are protected, allowing only one transaction to modify the
data at a time.

ADDITIONAL :-
List out the transaction properties ?
Mention the operation in transaction?

Difference between commit and rollback?


Commit
1. A COMMIT statement is used to save the changes on the
current transaction is permanent.
2. once the current transaction is completely executed using
the COMMIT command, it can't undo its previous state.
3. The COMMIT statement is applied when the transaction is
completed.
4. Commit;
RollBack
1. A Rollback statement is used to undo all the changes made
on the current transaction.
2. Whereas in the Rollback statement, once the current
transaction is successfully executed, it can reach its previous
state using the ROLLBACK command.
3. The Rollback statement occurs when the transaction is either aborted,
power failure, or incorrect execution of system failure.
4. Rollback;

You might also like