DEPARTMENT OF SOFTWARE

ENGINEERING

ADVANCED DATABASE
INDIVIDUAL ASSIGNMENT

NAME - HERAN SAMUEL TESFAMARIAM

ID – WCU/R1201261

SUBMITTED TO: INSTRUCTOR ABDIWAK

SUBMISSION DATE: MAY 10, 2022
1. What is Transactional support? Write in details about
Transactional Support in Advanced Database Management
Systems.
Before going into the meaning of transactional support let’s
see what is meant by transaction, Transaction is an
executing program that forms a logical unit of database
processing. Transaction includes one or more database
access operations these can include insertion, deletion,
modification, or retrieval operations. Transaction in
database system must maintain Atomicity, consistency,
isolation and durability-commonly known as ACID
properties in order to assure accuracy, completeness and
data integrity.
Example of transaction include paying a supplier for
services rendered or goods delivered, paying a seller with
cash and a note in order to obtain ownership of a property
formerly owned by the seller, paying an employee for hours
works.
Transaction support services normally step from the
financial investigation of a business or venture and
represent an essential part of the investment making
process or financing decision.
With SQL, transaction initiation is done implicitly when
particular SQL statements are encountered. However, every
transaction must have an explicit end statement, which is
either a COMMIT or ROLLBACK. Every transaction has
 certain characteristics attributed to it. The two transaction
statements provide transaction support.
 COMMIT statement— commit (make persistent) all
changes for the current transaction.
 ROLLBACK statement— rollback (rescind) all
changes for the current transaction.
A single SQL statement is always considered to be atomic.
o Either the statement completes execution
without error or it fails and leaves the database
unchanged.
Characteristics specified by a SET TRANSACTION statement
in SQL:
 Isolation level <isolation>, where <isolation> can be
READ UNCOMMITTED, READ COMMITTED,
REPEATABLE READ or SERIALIZABLE. The
default is SERIALIZABLE.
 With SERIALIZABLE: the interleaved execution of
transactions will adhere to our notion of serializability.
However, if any transaction executes at a lower level, then
serializability may be violated.
Potential problem with lower isolation levels:
Dirty Read: Reading a value that was written by a
transaction which failed.
 Non-repeatable Read:
 Allowing another transaction to write a new value
between multiple reads of one transaction.
 A transaction T1 may read a given value from a
table. If another transaction T2 later updates that
value and T1 reads that value again, T1 will see a
different value.
 Consider that T1 reads the employee salary for
Smith. Next, T2 updates the salary for Smith. If T1
reads Smith's salary again, then it will see a
different value for Smith's salary.
Potential problem with lower isolation levels (cont...):
Phantoms:New rows being read using the same read
with a condition.
A transaction T1 may read a set of rows from a table, perhaps
based on some condition specified in the SQL WHERE clause.
Now suppose that a transaction T2 inserts a new row that also
satisfies the WHERE clause condition of T1, into the table used
by T1.
If T1 is repeated, then T1 will see a row that previously did not
exist, called a phantom.
Table: Possible violation of serializabilty:
 Type of violation
Isolation level Dirty read Non- phantom
repeateable read
READ Yes Yes Yes
UNCOMMITTE
D
READ No Yes Yes
COMMITTED
REPEATABLE No No Yes
READ
SERIALIZABLE No No No

1. What are the problems of concurrent sharing in DBMS?

Write in details about concurrent sharing problems with the
help of real world examples.
Concurrency Control is the management procedure that is required
for controlling concurrent execution of the operations that take
place on a database.
Several problems can occur when concurrent transactions execute
in an uncontrolled manner. We illustrate some of these problems
by referring to a much simplified airline reservations database in
which a record is stored for each airline flight. Each record
includes the number of reserved seats on that flight as a named
(uniquely identifiable) data item, among other information. Figure
2.1(a) shows a transaction T1 that transfers N reservations from
one flight whose number of reserved seats is stored in the database
item named X to another flight whose number of reserved seats is
stored in the database item named Y. Figure 2.1(b) shows a
simpler transaction T2 that just reserves M seats on the first flight
(X) referenced in transaction T1. 2 To simplify our example, we do
not show additional portions of the transactions, such as checking
whether a flight has enough seats available before reserving
additional seats.
a)
T1
read_item(X);
X:=X-N;
write_item(X);
read_item(Y);
X:=Y+N;
write_item(Y);
b)
T2
read_item(X);
X:=X+M;
write_item(X);
Fig 2.1 Two sample transactions a) Transaction T1 and b)
Transaction T2

When a database access program is written, it has the flight

number, flight date, and the number of seats to be booked as
parameters; hence, the same program can be used to execute many
different transactions, each with a different flight number, date,
and number of seats to be booked. For concurrency control
purposes, a transaction is a particular execution of a program on a
specific date, flight, and number of seats. In Figure 2.1(a) and (b),
the transactions T1 and T2 are specific executions of the programs
that refer to the specific flights whose numbers of seats are stored
in data items X and Y in the database. Next we discuss the types of
 problems we may encounter with these two simple transactions if
they run concurrently.
1. The Lost Update Problem- This problem occurs when two
transactions that access the same database items have their
operations interleaved in a way that makes the value of some
database items incorrect. Suppose that transactions T1 and T2
are submitted at approximately the same time, and suppose that
their operations are interleaved as shown in Figure 2.2; then the
final value of item X is incorrect because T2 reads the value of
X before T1 changes it in the database, and hence the updated
value resulting from T1 is lost. For example, if X = 80 at the
start (originally there were 80 reservations on the flight), N = 5
(T1 transfers 5 seat reservations from the flight corresponding to
X to the flight corresponding to Y), and M = 4 (T2 reserves 4
seats on X), the final result should be X = 79. However, in the
interleaving of operations shown in Figure 2.2, it is X = 84
because the update in T1 that removed the five seats from X
was lost.
Fig 2.2 Lost update problem
T1 T2
read_item(X); read_item(X);
X:=X-N; X:=X+M;
write_item(X); write_item(X);
read_item(Y);
Y:=Y+N;
write_item(Y);
N.B Time is decreasing and item X has an incorrect value on T2
because its update by T1 is lost (overwritten).
2. The Temporary Update (or Dirty Read) Problem- This problem
occurs when one transaction updates a database item and then the
transaction fails for some reason. Meanwhile, the updated item is
accessed (read) by another transaction before it is changed back to
its original value. Figure 2.3 shows an example where T1 updates
item X and then fails before completion, so the system must
change X back to its original value. Before it can do so, however,
transaction T2 reads the temporary value of X, which will not be
recorded permanently in the database because of the failure of T1.
The value of item X that is read by T2 is called dirty data because
it has been created by a transaction that has not completed and
committed yet; hence, this problem is also known as the dirty read
problem.
Fig 2.3 Temporary problem

T1 T2
read_item(X);
X:=X-N;
write_item(X);
read_item(X);
X:=X+M;
write_item(X);
read_item(Y);
N.B Transaction T1 fails and must change the value of X back to
its old value; meanwhile T2 has read the temporary incorrect value
of X.
3. The Incorrect Summary Problem- If one transaction is
calculating an aggregate summary function on a number of
database items while other transactions are updating some of these
items, the aggregate function may calculate some values before
they are updated and others after they are updated. For example,
suppose that a transaction T3 is calculating the total number of
reservations on all the flights; meanwhile, transaction T1 is
executing. If the interleaving of operations shown in Figure 2.4
occurs, the result of T3 will be off by an amount N because T3
reads the value of X after N seats have been subtracted from it but
reads the value of Y before those N seats have been added to it.
Fig 2.4 Incorrect summary problem

T1 T3
sum:=0;

read_item(A);

sum:=sum+A;
read_item(X);

X:=X-N;

write_item(X);

read_item(X);

sum:=sum+X;

read_item(Y);

sum:=sum+Y;

read_item(Y);

Y:=Y+N;

write_item(Y);

N.B T3 reads X after N is subtracted and reads Y before N is

added; a wrong summary is the result (off by N).
4. The Unrepeatable Read Problem- Another problem that may
occur is called unrepeatable read, where a transaction T reads the
same item twice and the item is changed by another transaction T
between the two reads. Hence, T receives different values for its
two reads of the same item. This may occur, for example, if during
an airline reservation transaction, a customer inquires about seat
availability on several flights. When the customer decides on a
particular flight, the transaction then reads the number of seats on
that flight a second time before completing the reservation, and it
may end up reading a different value for the item.