Notesale: Turn your study into money

Document Preview

Extracts from the notes are below, to see the PDF you'll receive please use the links above

---

ADBMS-1

UNIT – 2
A transaction is a unit of program execution that accesses and possibly updates various data items
...
Generally a transaction reads a value from the
database or writes a value to the database
...

Although a transaction can both read and write on the database, there are some fundamental differences
between these two classes of operations
...

 But a write operation, whether performed with the intention of inserting, updating or deleting data from

the database, changes the image of the database
...

The Four Properties of Transactions
Every transaction, for whatever purpose it is being used, has the following four properties
...

Say for example, we have two accounts A and B, each containing Rs 1000/-
...

Read A;
A = A – 100;
Write A;
Read B;
B = B + 100;
Write B;
Fine, is not it?
The transaction has 6 instructions to extract the amount from A and submit it to B
...

Now, suppose there is a power failure just after instruction 3 (Write A) has been complete
...
It would be said that Rs
100/- evaporated in thin air for the power failure
...

The solution is to keep every value calculated by the instruction of the transaction not in any stable storage (hard
disc) but in a volatile storage (RAM), until the transaction completes its last instruction
...
Its job is to write every temporarily calculated
value from the volatile storage on to the stable storage
...


ADBMS-2

UNIT – 2
If we execute a particular transaction in isolation or together with other transaction, (i
...
presumably in a multiprogramming environment), the transaction will yield the same expected result
...
Concurrently executing transactions may have to deal with the problem of sharable resources, i
...
resources
that multiple transactions are trying to read/write at the same time
...
g
...
Careful mechanisms are created in order to prevent mismanagement of these sharable resources, so that there
should not be any change in the way a transaction performs
...


In case multiple transactions are executing concurrently and trying to access a sharable resource at the same time,
the system should create an ordering in their execution so that they should not create any anomaly in the value
stored at the sharable resource
...
Again, if
you have the concept of Operating Systems, then you should remember the semaphores, how it is used by a process
to make a resource busy before starting to use it, and how it is used to release the resource after the usage is over
...
Locking is almost similar
...
Once a transaction locks the data item, other transactions wishing to access
the same data item must wait until the lock is released
...

As we have seen in the explanation of the Atomicity property, the transaction, if completes successfully, is
committed
...
So, after the transaction has been committed successfully, there is no
question of any loss of information even if the power fails
...

There are several ways Atomicity and Durability can be implemented
...
In this
scheme a database pointer is used to point to the BFIM of the database
...
Now, if the transaction is required to COMMIT, then the database pointer is
updated to point to the AFIM copy, and the BFIM copy is discarded
...
It keeps pointing to the BFIM, and the AFIM is discarded
...

If you study carefully, you can understand that

, just as

...

Partially Committed: At any given point of time if the transaction is executing properly, then it is going towards it
COMMIT POINT
...


Failed: If the transaction fails for some reason
...
It means that any change made to the database by this transaction up to the point of the failure
must be undone
...
100/- from account A, then the ROLLBACK operation
should add Rs 100/- to account A
...
The transaction is now said to
have been aborted
...
All the temporary values are
written to the stable storage and the transaction is said to have been committed
...

The whole process can be described using the following diagram:

Figure 1-Transaction States

Concurrent Execution
A schedule is a collection of many transactions which is implemented as a unit
...

Concurrent: The transactions are executed in a preemptive, time shared method
...
However, a serial schedule is inefficient in the sense that
the transactions suffer for having a longer waiting time and response time, as well as low amount of resource
utilization
...

However, this creates the possibility that more than one transaction may need to access a single data item for
read/write purpose and the database could contain inconsistent value if such accesses are not handled properly
...


T1

T2

Read A;

Read A;

A = A – 100;

Temp = A * 0
...

T2 is a new transaction which deposits to account C 10% of the amount in account A
...

then

Some Context Switching need to be made, so that some portion of T1 will be executed, then some portion of T2 will
be executed and so on
...


T1

T2

Read A;
A = A - 100;
Write A;
Read A;
Temp = A * 0
...
We have made some Context Switching in this Schedule, the first one after executing the third
instruction of T1, and after executing the last statement of T2
...
T2 reads the value of A, calculates the value of Temp to be Rs 90/- and adds the value to C
...


ADBMS-5

UNIT – 2
It is clear that a proper Context Switching is very important in order to maintain the Consistency and Isolation
properties of the transactions
...
Consider the following example involving the same T1 and T2

T1

T2

Read A;
A = A - 100;
Read A;
Temp = A * 0
...
The result is very
confusing
...
But in
this wrong schedule, the Context Switching is being performed before the new value of Rs 900/- has been updated in
A
...
C makes an unjust gain of Rs 10/out of nowhere
...
But
there must be some well-formed rules regarding how to arrange instructions of the transactions to create error free
concurrent schedules
...


Serializability
When several concurrent transactions are trying to access the same data item, the instructions within these
concurrent transactions must be ordered in some way so as there are no problem in accessing and releasing the
shared data item
...

Conflict Serializability deals with detecting whether the instructions are conflicting in any way, and specifying the
order in which these two instructions will be executed in case there is any conflict
...

The following rules are important in Conflict Serializability:
 If two instructions of the two concurrent transactions are both for read operation, then they are not in
conflict, and can be allowed to take place in any order
...

 If the read instruction is performed first, then it reads the old value of the data item and
after the reading is over, the new value of the data item is written
...


ADBMS-6

UNIT – 2


If both the transactions are for write operation, then they are in conflict but can be allowed to take place
in any order, because the transaction do not read the value updated by each other
...

Instructions li and lj of transactions Ti and Tj respectively, conflict if and only if there exists
some item Q accessed by both li and lj, and at least one of these instructions wrote Q
...
li = read(Q), lj = read(Q)
...

2
...
They conflict
...
li = write(Q), lj = read(Q)
...
li = write(Q), lj = write(Q)
...

Keeping in mind these rules, we may sometimes alter parts of one schedule (S1) to create another schedule (S2) by
swapping only the non-conflicting parts of the first schedule
...
If these two schedules are made of the same set of transactions, then both S1 and S2 would
yield the same result if the conflict resolution rules are maintained while creating the new schedule
...

Schedule 3 can be transformed into Schedule 6, a serial schedule where T2 follows T1, by series of swaps of nonconflicting instructions
...


This is another type of Serializability that can be derived by creating another
schedule out of an existing schedule, involving the same set of transactions
...


Let us consider that the transactions T1 and T2 are being serialized to create two different schedules S1 and S2
which we want to be View Equivalent and both T1 and T2 wants to access the same data item
...

If in S1, T1 writes a value in the data item which is read by T2, then in S2 also, T1 should write the value in
the data item before T2 reads it
...


Except in these three cases, any alteration can be possible while creating S2 by modifying S1

---