CH 3 Lecture 2

Bangladesh Army University of Engineering and Technology (BAUET)
Qadirabad Cantonment, Natore.
Department of Information and Communication Engineering (ICE)
ICE 4261: Internet and Web Programming

Chapter: Web Programming
Lecture-2
Prepared By
Mehedi Hasan Imran
Lecturer, BAUET
Dept. of ICE
Email: imran02@bauet.ac.bd
DBMS - 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 Y's Account

Open_Account(X) Open_Account(Y)
Old_Balance = X.balance Old_Balance = Y.balance
New_Balance = Old_Balance - 800 New_Balance = Old_Balance + 800
X.balance = New_Balance Y.balance = New_Balance
Close_Account(X) Close_Account(Y)
03/25/2023 Mehedi Hasan Imran, Lecturer, Department of Information and Communication Engineering 2
Operations of 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.
Commit: It is used to save the work done permanently.
Rollback: It is used to undo the work done.
Property of Transaction
ACID Properties
ACID Properties
1) Atomicity: The term atomicity defines that the data remains atomic. It means if any operation is performed
on the data, either it should be performed or executed completely or should not be executed at all. It further
means that the operation should not break in between or execute partially. In the case of executing operations
on the transaction, the operation should be completely executed and not partially.
ACID Properties
2) Consistency: The word consistency means that the value should remain preserved always. In DBMS, the
integrity of the data should be maintained, which means if a change in the database is made, it should remain
preserved always. In the case of transactions, the integrity of the data is very essential so that the database
remains consistent before and after the transaction. The data should always be correct.
ACID Properties
3) Isolation: The term 'isolation' means separation. In DBMS, Isolation is the property of a database where no
data should affect the other one and may occur concurrently. In short, the operation on one database should
begin when the operation on the first database gets complete. It means if two operations are being performed
on two different databases, they may not affect the value of one another. In the case of transactions, when two
or more transactions occur simultaneously, the consistency should remain maintained. Any changes that occur
in any particular transaction will not be seen by other transactions until the change is not committed in the
memory.
ACID Properties
4) Durability: Durability ensures the permanency of something. In DBMS, the term durability ensures that the
data after the successful execution of the operation becomes permanent in the database. The durability of the
data should be so perfect that even if the system fails or leads to a crash, the database still survives. However, if
gets lost, it becomes the responsibility of the recovery manager for ensuring the durability of the database. For
committing the values, the COMMIT command must be used every time we make changes.
Therefore, the ACID property of DBMS plays a vital role in maintaining the consistency and availability of data
in the database.
Schedule
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.
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.
For example: Suppose there are two transactions T1 and T2 which have some operations. If it has no interleaving of
operations, then there are the following two possible outcomes:
1.Execute all the operations of T1 which was followed by all the operations of T2.
2.Execute all the operations of T1 which was followed by all the operations of T2.
•In the given (a) figure, Schedule A shows the serial schedule where T1 followed by T2.
•In the given (b) figure, Schedule B shows the serial schedule where T2 followed by T1.
Non-serial Schedule
•If interleaving of operations is allowed, then there will be non-serial schedule.

•It contains many possible orders in which the system can execute the individual operations of the transactions.
•In the given figure (c) and (d), Schedule C and Schedule D are the non-serial schedules. It has interleaving of
operations.
Serializable schedule
•The serializability of schedules is used to find non-serial schedules that allow the transaction to execute concurrently
without interfering with one another.
•It identifies which schedules are correct when executions of the transaction have interleaving of their operations.
•A non-serial schedule will be serializable if its result is equal to the result of its transactions executed serially.
States of Transactions
•Active − In this state, the transaction is being executed. This is the initial state of every transaction.
•Partially Committed − When a transaction executes its final operation, it is said to be in a partially committed
state.
•Failed − A transaction is said to be in a failed state if any of the checks made by the database recovery system fails.
A failed transaction can no longer proceed further.
•Aborted − If any of the checks fails and the transaction has reached a failed state, then the recovery manager rolls
back all its write operations on the database to bring the database back to its original state where it was prior to the
execution of the transaction. Transactions in this state are called aborted. The database recovery module can select
one of the two operations after a transaction aborts −
• Re-start the transaction
• Kill the transaction
•Committed − If a transaction executes all its operations successfully, it is said to be committed. All its effects are
now permanently established on the database system.
DBMS - Concurrency Control
In a multiprogramming environment where multiple transactions can be executed simultaneously, it is highly

important to control the concurrency of transactions. We have concurrency control protocols to ensure atomicity,
isolation, and serializability of concurrent transactions. Concurrency control protocols can be broadly divided into
two categories −
•Lock based protocols
•Time stamp based protocols
Lock-based Protocols
Database systems equipped with lock-based protocols use a mechanism by which any transaction cannot read or
write data until it acquires an appropriate lock on it. Locks are of two kinds −
•Binary Locks − A lock on a data item can be in two states; it is either locked or unlocked.
•Shared/exclusive − This type of locking mechanism differentiates the locks based on their uses. If a lock is
acquired on a data item to perform a write operation, it is an exclusive lock. Allowing more than one transaction to
write on the same data item would lead the database into an inconsistent state. Read locks are shared because no data
value is being changed.
Four Types of Lock Protocols
Simplistic Lock Protocol

Simplistic lock-based protocols allow transactions to obtain a lock on every object before a 'write' operation is
performed. Transactions may unlock the data item after completing the ‘write’ operation.
Pre-claiming Lock Protocol

Pre-claiming protocols evaluate their operations and create a list of data items on which they need locks. Before
initiating an execution, the transaction requests the system for all the locks it needs beforehand. If all the locks are
granted, the transaction executes and releases all the locks when all its operations are over. If all the locks are not
granted, the transaction rolls back and waits until all the locks are granted.
Four Types of Lock Protocols
Two-Phase Locking 2PL

This locking protocol divides the execution phase of a transaction into three parts. In the first part, when the
transaction starts executing, it seeks permission for the locks it requires. The second part is where the transaction
acquires all the locks. As soon as the transaction releases its first lock, the third phase starts. In this phase, the
transaction cannot demand any new locks; it only releases the acquired locks.
Two-phase locking has two phases, one is growing, where all the locks are being
acquired by the transaction; and the second phase is shrinking, where the locks held by
the transaction are being released.
To claim an exclusive (write) lock, a transaction must first acquire a shared (read) lock
and then upgrade it to an exclusive lock.
Strict Two-Phase Locking
The first phase of Strict-2PL is same as 2PL. After acquiring all the locks in the first phase, the transaction continues
to execute normally. But in contrast to 2PL, Strict-2PL does not release a lock after using it. Strict-2PL holds all the
locks until the commit point and releases all the locks at a time. Strict-2PL does not have cascading abort as 2PL
does.
Timestamp-based Protocols
The most commonly used concurrency protocol is the timestamp based protocol. This protocol uses either system
time or logical counter as a timestamp.
Lock-based protocols manage the order between the conflicting pairs among transactions at the time of execution,
whereas timestamp-based protocols start working as soon as a transaction is created.
Every transaction has a timestamp associated with it, and the ordering is determined by the age of the transaction. A
transaction created at 0002 clock time would be older than all other transactions that come after it. For example, any
transaction 'y' entering the system at 0004 is two seconds younger and the priority would be given to the older one.
In addition, every data item is given the latest read and write-timestamp. This lets the system know when the last
‘read and write’ operation was performed on the data item.
Timestamp Ordering Protocol
The timestamp-ordering protocol ensures serializability among transactions in their conflicting read and write
operations. This is the responsibility of the protocol system that the conflicting pair of tasks should be executed
according to the timestamp values of the transactions.
 The timestamp of transaction Ti is denoted as TS(Ti).

 Read time-stamp of data-item X is denoted by R-timestamp(X).
 Write time-stamp of data-item X is denoted by W-timestamp(X).
DBMS - Deadlock
In a database, a deadlock is an unwanted situation in which two or more transactions are waiting indefinitely
for one another to give up locks. Deadlock is said to be one of the most feared complications in DBMS as it
brings the whole system to a Halt.
Example – let us understand the concept of Deadlock with an example :
Suppose, Transaction T1 holds a lock on some rows in the Students table and needs to update some rows in
the Grades table. Simultaneously, Transaction T2 holds locks on those very rows (Which T1 needs to update)
in the Grades table but needs to update the rows in the Student table held by Transaction T1.
Now, the main problem arises. Transaction T1 will wait for transaction T2 to give up the lock, and similarly,
transaction T2 will wait for transaction T1 to give up the lock. As a consequence, All activity comes to a halt
and remains at a standstill forever unless the DBMS detects the deadlock and aborts one of the transactions.
DBMS - Deadlock
Deadlock Avoidance
•When a database is stuck in a deadlock state, then it is better to avoid the database rather than aborting or
restating the database. This is a waste of time and resource.
•Deadlock avoidance mechanism is used to detect any deadlock situation in advance. A method like "wait for
graph" is used for detecting the deadlock situation but this method is suitable only for the smaller database.
For the larger database, deadlock prevention method can be used.
Deadlock Detection
In a database, when a transaction waits indefinitely to obtain a lock, then the DBMS should detect whether the
transaction is involved in a deadlock or not. The lock manager maintains a Wait for the graph to detect the
deadlock cycle in the database.
DBMS - Deadlock
Wait for Graph

•This is the suitable method for deadlock detection. In this method, a graph is created based on the transaction
and their lock. If the created graph has a cycle or closed loop, then there is a deadlock.
•The wait for the graph is maintained by the system for every transaction which is waiting for some data held
by the others. The system keeps checking the graph if there is any cycle in the graph.
The wait for a graph for the above scenario is shown below:
DBMS - Deadlock
Deadlock Prevention
•Deadlock prevention method is suitable for a large database. If the resources are allocated in such a way that
deadlock never occurs, then the deadlock can be prevented.
•The Database management system analyzes the operations of the transaction whether they can create a
deadlock situation or not. If they do, then the DBMS never allowed that transaction to be executed.
Log-Based Recovery
 The log is a sequence of records. Log of each transaction is maintained in some stable storage so that if any
failure occurs, then it can be recovered from there.
 If any operation is performed on the database, then it will be recorded in the log.
 But the process of storing the logs should be done before the actual transaction is applied in the database.
When the transaction is initiated, then it writes 'start' log.

<Tn, Start>
When the transaction modifies the City from ‘Natore' to ‘Rajshahi', then another log is written to the file.
<Tn, City, ' Natore', ' Rajshahi' >
When the transaction is finished, then it writes another log to indicate the end of the transaction.
<Tn, Commit>
Log-Based Recovery
Log is nothing but a file which contains a sequence of records, each log record refers to a write operation. All the log
records are recorded step by step in the log file. We can say, log files store the history of all updates activities.
Log contains start of transaction, transaction number, record number, old value, new value, end of transaction etc.
For example, mini statements in bank ATMs.
If within an ongoing transaction, the system crashes, then by using log files, we can return back to the previous state
as if nothing has happened to the database.
The log is kept on disk so that it is not affected by failures except disk and failures.
Example
Different types of log records are as follows −
•<Ti, Xi, V1, V2> − update log record, where Ti=transaction, Xi=data, V1=old data, V2=new value.
•<Ti, start> − Transaction Ti starts execution.
•<Ti, commit> − Transaction Ti is committed.
•<Ti, abort> − Transaction Ti is aborted
Log-Based Recovery
The log records can be written as follows −
Deferred Database Modification
It modifies the database after completion of transaction. The database modification is deferred or delayed until the
last operation of the transaction is executed. Update log records maintain the new value of the data item.
Recover system uses one operation which is as follows −
•Redo(Ti) − All data items updated by the transaction Ti are set to a new value.
Immediate Database Modification
It modifies the database after a write operation, database modification is immediately done when a
transaction performs an update/ write operation. Update log records maintain both old and new values of
data items.
The recovery system uses two operations, which are as follows −
•Undo(Ti) − All data items updated by the transaction Ti, are set to old value.
•Redo(Ti) − All data items updated by the transaction Ti are set to a new value.
Checkpoint
•The checkpoint is a type of mechanism where all the previous logs are removed from the system and
permanently stored in the storage disk.
•The checkpoint is like a bookmark. While the execution of the transaction, such checkpoints are marked,
and the transaction is executed then using the steps of the transaction, the log files will be created.
•When it reaches to the checkpoint, then the transaction will be updated into the database, and till that
point, the entire log file will be removed from the file. Then the log file is updated with the new step of
transaction till next checkpoint and so on.
•The checkpoint is used to declare a point before which the DBMS was in the consistent state, and all
transactions were committed.
Recovery using Checkpoint
•The recovery system reads log files from the end to start.
It reads log files from T4 to T1.
•Recovery system maintains two lists, a redo-list, and an
undo-list.
•The transaction is put into redo state if the recovery
system sees a log with <Tn, Start> and <Tn, Commit> or
just <Tn, Commit>. In the redo-list and their previous list,
all the transactions are removed and then redone before
saving their logs.
Recovery using Checkpoint
•For example: In the log file, transaction T2 and T3 will have <Tn, Start> and <Tn, Commit>. The T1 transaction
will have only <Tn, commit> in the log file. That's why the transaction is committed after the checkpoint is crossed.
Hence it puts T1, T2 and T3 transaction into redo list.
•The transaction is put into undo state if the recovery system sees a log with <Tn, Start> but no commit or abort log
found. In the undo-list, all the transactions are undone, and their logs are removed.
•For example: Transaction T4 will have <Tn, Start>. So T4 will be put into undo list since this transaction is not yet
complete and failed amid.
DBMS Concurrency Control
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.
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.
•At time t1, transaction TX reads the value of account A, i.e., $300 (only read).
•At time t2, transaction TX deducts $50 from account A that becomes $250 (only deducted and not updated/write).
•Alternately, at time t3, transaction TY reads the value of account A that will be $300 only because T X didn't update
the value yet.
•At time t4, transaction TY adds $100 to account A that becomes $400 (only added but not updated/write).
•At time t6, transaction TX writes the value of account A that will be updated as $250 only, as T Y didn't update the
value yet.
•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:
Dirty Read Problems (W-R Conflict)
•At time t1, transaction TX reads the value of account A, i.e., $300.
•At time t2, transaction TX adds $50 to account A that becomes $350.
•At time t3, transaction TX writes the updated value in account A, i.e., $350.
•Then at time t4, transaction TY reads account A that will be read as $350.
•Then at time t5, transaction TX rollbacks due to server problem, and the value changes back to $300 (as
initially).
•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. The diagram is shown below:
Unrepeatable Read Problem (W-R Conflict)
•At time t1, transaction TX reads the value from account A, i.e., $300.
•At time t2, transaction TY reads the value from account A, i.e., $300.
•At time t3, transaction TY updates the value of account A by adding $100 to the available balance, and then it
becomes $400.
•At time t4, transaction TY writes the updated value, i.e., $400.
•After that, at time t5, transaction TX reads the available value of account A, and that will be read as $400.
•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.
OLTP vs OLAP
Online transaction processing (OLTP): Online transaction processing provides transaction-oriented

applications in a 3-tier architecture. OLTP administers the day-to-day transactions of an organization.
Examples: Uses of OLTP are as follows:
•ATM center is an OLTP application.
•OLTP handles the ACID properties during data transactions via the application.
•It’s also used for Online banking, Online airline ticket booking, sending a text message, add a book to the
shopping cart.
Online Analytical Processing (OLAP): Online Analytical Processing consists of a type of software tools that
are used for data analysis for business decisions. OLAP provides an environment to get insights from the
database retrieved from multiple database systems at one time. Examples – Any type of Data warehouse
system is an OLAP system.
OLTP vs OLAP
E-Commerce Web Site

Name:
Phone:
Address:
OLAP OLTP
Name Phone Address Name Phone Address

Imran 017….. Jhenaidah Imran 017….. Jhenaidah
Thank You All

CH 3 Lecture 2

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CH 3 Lecture 2

Uploaded by

Copyright:

Available Formats

Bangladesh Army University of Engineering and Technology (BAUET)

Qadirabad Cantonment, Natore.

Department of Information and Communication Engineering (ICE)

ICE 4261: Internet and Web Programming

X's Account Y's Account

•If interleaving of operations is allowed, then there will be non-serial schedule.

In a multiprogramming environment where multiple transactions can be executed simultaneously, it is highly

Simplistic Lock Protocol

Pre-claiming Lock Protocol

Two-Phase Locking 2PL

 The timestamp of transaction Ti is denoted as TS(Ti).

Wait for Graph

When the transaction is initiated, then it writes 'start' log.

The recovery system uses two operations, which are as follows −

Problem 1: Lost Update Problems (W - W Conflict)

Online transaction processing (OLTP): Online transaction processing provides transaction-oriented

E-Commerce Web Site

Name Phone Address Name Phone Address

You might also like