2. What is meant by the concurrent execution of database transactions in
a
multiuser system? Discuss why concurrency control is needed, and
give
informal examples.
Concurrent execution of database transactions in a multi-user system means that any number of users can use the same database at the same time.
Concurrency control is needed in order to avoid inconsistencies in the database.
Here is an example of how this scenario can lead to an inconsistency:
Assume we have two users, Alice and Bob, who both have access to the same bank account. Alice wants to deposit $100 and Bob wants to withdraw
$200. Assuming there is $500 in the account, here is how the execution might take place if they perform their actions at the same time:
1. Alice gets initial amount (x = $500)
2. Bob gets initial amount (x = $500)
3. Alice deposits $100 (x + 100) = $600
4. Bob withdraws $200 (x - 200) = $300
5. Alice saves the new balance ($600)
6. Bob saves the new balance ($300)
New balance after both actions should be $400. Now the database is in an inconsistent state.
Concurrency control can prevent inconsistencies by providing Alice with a temporary "lock" on the database until she is done with her action.
3. Discuss the different types of failures.
What is meant by catastrophic
failure?
Failures are generally classified as transaction, system, and
media failures. There are several possible reasons for a
transaction to fail in the middle of execution:
System crash – A hardware, software, or network error
occurs in the computer system during transaction
execution. Hardware crashes are usually media failures.
A transaction or system error – Some operation in the
transaction may cause it to fail, such as integer overflow or
division by zero.
Local errors or exception conditions detected by the
transaction – During transaction execution,...
Catastrophic failure is a complete, sudden, often
unexpected breakdown in a machine, electronic
system, computer or network. Such a breakdown may
occur as a result of a hardware event such as a disk drive
crash, memory chip failure or surge on the power line.
4. What is a schedule (history)? Define the concepts of recoverable,
cascadeless,
and strict schedules, and compare them in terms of their
recoverability.
A schedule (or history) of a system is an abstract model to describe execution of
transactions running in the system. Often it is a list of operations (actions) ordered by
time, performed by a set of transactions that are executed together in the system. If
order in time between certain operations is not determined by the system, then a
partial order is used. Examples of such operations are requesting a read operation,
reading, writing, aborting, committing, requesting lock, locking, etc. Not all
transaction operation types should be included in a schedule, and typically only
selected operation types (e.g., data access operations) are included, as needed to
reason about and describe certain phenomena. Schedules and schedule properties are
fundamental concepts in database concurrency control theory.
A schedule S of n transaction T1,T2,T3...Tr. is an ordering of the operations of the
transaction subject to the constraint that, for each transaction T1 that participates in S,
the operations of Ti in S must appear in the same order in which they occur in Ti.
If we can ensure that s transaction T, when committed, never has to roll back, then we
have a demarcation between recoverable and non-recoverable schedules. Schedules
determains as non-recoverable should not be permitted.Among the recoverable
schedules, transaction failures generates a spectrum of recoverability, from easy to
complex.
5. Discuss the different measures of transaction equivalence. What is the
difference
between conflict equivalence and view equivalence?
S.No. Conflict Serializability View Serializability
1.
Two schedules are said to be conflict equivalent if all the
conflicting operations in both the schedule get executed in the
same order. If a schedule is a conflict equivalent to its serial
schedule then it is called Conflict Serializable Schedule.
Two schedules are said to be view
equivalent if the order of initial read,
final write and update operations is
the same in both the schedules. If a
schedule is view equivalent to its
serial schedule then it is called View
Serializable Schedule.
2.
If a schedule is view serializable then it may or may not be conflict
serializable.
If a schedule is conflict serializable
then it is also view serializable
schedule.
3.
Conflict equivalence can be easily achieved by reordering the
operations of two transactions therefore, Conflict Serializability is
easy to achieve.
Viewequivalence is rather difficult to
achieve as both transactions should
perform similar actions in a similar
manner. Thus, View Serializability is
difficult to achieve.
4.
For a transaction T1 writing a value A that no one else reads but
later some other transactions say T2 write its own value of A,
W(A) cannot be placed under positions where it is never read.
If a transaction T1 writes a value A
that no other transaction reads
(because later some other
transactions say T2 writes its own
value of A) W(A) can be placed in
positions of the schedule where it is
never read.
6. Discuss how serializability is used to enforce concurrency control in a
database
system. Why is serializability sometimes considered too restrictive as a
measure of correctness for schedules?
A concurrency control is said to be serializable if the
final result of that schedule istotally same as the final
result given by the serial schedule. So in executing
transaction it will be allowed to access multiple
transaction with the DBMS in orders to enhance the
efficiency and the maximum usability of the
resources. But it should give the same result for
particular transaction, otherwise it is useless. So
through serializability it will lead to the same final
outcome...
7. Conflict Serializability in DBMS
As discussed in Concurrency control, serial schedules have
less resource utilization and low throughput. To improve it,
two or more transactions are run concurrently. But
concurrency of transactions may lead to inconsistency in
database. To avoid this, we need to check whether these
concurrent schedules are serializable or not.
Conflict Serializable: A schedule is called conflict
serializable if it can be transformed into a serial schedule by
swapping non-conflicting operations.
Conflicting operations: Two operations are said to be
conflicting if all conditions satisfy:
1. They belong to different transactions
2. They operate on the same data item
3. At Least one of them is a write operation
8. Example: –
Conflicting operations pair (R1(A), W2(A))
because they belong to two different transactions
on same data item A and one of them is write
operation.
Similarly, (W1(A), W2(A)) and (W1(A), R2(A)) pairs
are also conflicting.
On the other hand, (R1(A), W2(B)) pair is non-
conflicting because they operate on different
data item.
Similarly, ((W1(A), W2(B)) pair is non-conflicting.
9. Consider the following schedule:
S1: R1(A), W1(A), R2(A), W2(A), R1(B), W1(B), R2(B),
W2(B)
If Oi and Oj are two operations in a transaction and Oi< Oj (Oi is executed
before Oj), same order will follow in the schedule as well. Using this
property, we can get two transactions of schedule S1 as:
T1: R1(A), W1(A), R1(B), W1(B)
T2: R2(A), W2(A), R2(B), W2(B)
Possible Serial Schedules are: T1->T2 or T2->T1
-> Swapping non-conflicting operations R2(A) and R1(B) in S1, the schedule becomes,
S11: R1(A), W1(A), R1(B), W2(A), R2(A), W1(B), R2(B), W2(B)
-> Similarly, swapping non-conflicting operations W2(A) and W1(B) in S11, the schedule becomes,
S12: R1(A), W1(A), R1(B), W1(B), R2(A), W2(A), R2(B), W2(B)
S12 is a serial schedule in which all operations of T1 are performed before starting any operation of T2. Since S has
been transformed into a serial schedule S12 by swapping non-conflicting operations of S1, S1 is conflict serializable.
10. Let us take another Schedule:
S2: R2(A), W2(A), R1(A), W1(A), R1(B), W1(B),
R2(B), W2(B) Two transactions will be:
T1: R1(A), W1(A), R1(B), W1(B)
T2: R2(A), W2(A), R2(B), W2(B)
Possible Serial Schedules are: T1->T2 or T2->T1
Original Schedule is:
S2: R2(A), W2(A), R1(A), W1(A), R1(B), W1(B), R2(B), W2(B)
Swapping non-conflicting operations R1(A) and R2(B) in S2, the schedule becomes,
S21: R2(A), W2(A), R2(B), W1(A), R1(B), W1(B), R1(A), W2(B)
Similarly, swapping non-conflicting operations W1(A) and W2(B) in S21, the schedule becomes,
S22: R2(A), W2(A), R2(B), W2(B), R1(B), W1(B), R1(A), W1(A)
In schedule S22, all operations of T2 are performed first, but operations of T1 are not in order
(order should be R1(A), W1(A), R1(B), W1(B)). So S2 is not conflict serializable.
11. Conflict Equivalent: Two schedules are said to be
conflict equivalent when one can be transformed to
another by swapping non-conflicting operations. In the
example discussed above, S11 is conflict equivalent
to S1 (S1 can be converted to S11 by swapping non-
conflicting operations). Similarly, S11 is conflict
equivalent to S12 and so on.
Note 1: Although S2 is not conflict serializable, but
still it is conflict equivalent to S21 and S21 because
S2 can be converted to S21 and S22 by swapping
non-conflicting operations.
Note 2: The schedule which is conflict serializable is
always conflict equivalent to one of the serial
schedule. S1 schedule discussed above (which is
conflict serializable) is equivalent to serial schedule
(T1->T2).
