Explain DBMS Transactions
Explain DBMS Transactions: Transaction management is a very interesting and important concept in DBMS as it is related to our daily life. We withdraw the amount, deposit the cash, also the process of withdrawing the money in ATM as we first insert the ATM card, enter the pin number, such simple tasks are nothing but transactions. The transaction can be defined as the group of tasks or the program unit which after execution changes the contents of a database.
Explain DBMS Transactions
Let us take an example of a simple transaction. Suppose your bank account database has an amount of 7000 and you withdraw 4000 from it. let M and N indicate the cash before and after withdrawing in your ATM. The transaction can be represented as shown
This table forms a transaction. The amount initially was 7000 was later updated to 4000, thus the statement that says it is a unit which changes its database contents after executing is true.
ACID PROPERTIES
Atomicity – It states that a transaction should be treated as an atomic unit which means all the operations are executed or none is executed. It is as simple as saying transaction will run to completion as an individual unit, where either no changes occurs to the database or database has been changed in a consistent manner. States must be defined before or after the execution/failure of the transaction.
Consistency – It states that after a transaction, the database must remain in a consistent state. The transaction should not have any adverse effect on the content of a database. It ensures that if the database was in a consistent state before transaction then even on the termination it should be in the consistent state.
Isolation – It states that if more than one transaction is being executed simultaneously, then all the transactions are executed such that it occurs as only one transaction is being executed in the system. One transaction should not affect the other transaction or its operation.
Durability – It states that even if the system is failed or restarted, the database must be durable to hold all its updates.Database has to hold all the modified data. The commit action of a transition on its termination will be reflected in the database.
STATES OF A TRANSACTION
Active: This is initial of all stages. As the transaction is made, it enters into this stage. Transaction is said to be in the active state when it gets executed performing read or write operation.
Partially committed: When a transaction comes to an end after executing its final operation, it enters into a partially committed stage.
Committed:If transaction is successful in executing all operations it is said to be committed.
Failed: It can be either from active or partially committed stage. If database recovery system fails in any of the checks made, then it is said to be in failed state. Failed transaction can never be proceeded.
Aborted: Suppose the check fails and transaction reaches failed state, then recovery manager rolls back its write operation to get the database back to the original stage. After a transaction aborts, database recovery model can select either of two operations- Re-start the transaction or kill the transaction.
This can be understood with an example. Suppose you are at the ATM, now you have entered the pin no which can be related to the active state. You either check the balance or withdraw the cash which can be compared with operations like read and write. If you withdraw it successfully, then it enters committed state and gets terminated otherwise enters the failed state.
SERIALIZABILITY
If multiple transactions are being executed in a multi-programming environment, then it is obvious there are possibilities that one transaction can be interleaved with the other. The execution sequence of instruction of a transaction cannot be changed but can be executed in a random fashion.
- Schedule: A sequential execution of a transaction with respect to time is called a schedule which can have many transactions in it, each compromising several tasks in it.
- Serial schedule: Transactions are executed in a serial way, which are ordered one after the other. It is the schedule where transactions are aligned such that when the first transaction finishes its cycle, second starts. When second finishes third starts and so on.
If two transactions are on a different segment of data then executing their instructions in a random fashion will cause no problem. But if on the same data, then the result will vary and dissatisfies the property of consistency. So the parallel execution of a transaction schedule is allowed in order to resolve this problem based on the condition that transactions are either serializable or have equivalence relation among them.
Equivalence schedules can be of three types as follows
- Result equivalence – After an execution, if and only if two schedules have the same result is it said to be result equivalence. This is not significant since it produces the same result for some set of values and different results for another set of values.
- Conflict equivalence – Two schedules are said to be conflicting if they satisfy below criteria
- Both belong to separate transactions.
- Both should access the same data item.
- At least one of them is a write operation.
3. View equivalence – If transactions in both schedules perform same actions in a similar manner then it is considered as view equivalence.
Leave a Reply