dbms

• Transaction


  A set of logically related operations. It contains a group of tasks
• Transaction


  An action or series of actions performed by a single user to access the contents of the database
• Transaction


  • An employee of a bank transfers Rs 800 from X's account to Y's account
• Operations of a Transaction

  1. Read(X): Read the value of X from the database and store it in a buffer

  2. Write(X): Write the value back to the database from the buffer
• Example of a debit transaction from an account
• Commit


  Used to save the work done permanently
• Rollback


  Used to undo the work done
• Commit and Rollback are used to maintain consistency in a database, before and after the transaction
• If a transaction fails after the completion of one part but before the completion of another part, it leads to an inconsistent database state
• Atomicity


  • The transaction must be executed in entirety
• Isolation


  • The data used by a transaction cannot be used by another transaction until the first one is completed
• Durability


  • The changes made by a completed transaction are permanent and cannot be lost
• Consistency


  • Integrity constraints must be maintained so that the database is consistent before and after the transaction
• States of a Transaction

  • Active state
  • Partially committed
  • Committed
  • Failed state
  • Aborted
• Schedule


  The sequence of operations performed by multiple transactions running concurrently
• Serial Schedule


  A transaction is executed completely before starting the execution of another transaction
• For n transactions, there exist n! different valid serial schedules
• Concurrent Schedule


  The instructions of the transactions are executed preemptively, with the CPU time shared among all the transactions
• Non-Serial Schedule


  The operations of the transactions are interleaved
• The total number of non-serial schedules is the total number of schedules minus the total number of serial schedules
• Serializability


  A non-serial schedule is serializable if its result is equal to the result of its transactions executed serially
• Testing Serializability


  Construct a precedence graph for the schedule, with vertices representing the transactions and edges representing the order of operations
• 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.
• Serializability


  If a schedule of concurrent 'n' transactions can be converted into an equivalent serial schedule, then we can say that the schedule is serializable.
• Testing of Serializability


  To test the serializability of a schedule, we can use the serialization graph.
• Precedence graph


  A graph with a pair G = (V, E), where E consists of a set of edges, and V consists of a set of vertices. The set of vertices contain all the transactions participating in the S schedule. The set of edges contains all edges Ti -> Tj.
• Schedule S


  • T1 Read(A) -> T2 A=A+50 -> T1 Write(A) -> T2 Read(A) -> T2 A=A+100 -> T2 Write(A)
• Schedule S1


  • T1 Read(A) -> T2 Read(A) -> T1 Write(A) -> T2 Write(A)
• If we can convert a Non Serial Schedule in any of the possible Serial Schedule then we can say that the schedule is Serializable.
• Conflict Serializability


  A schedule will be given and we need to check that is given schedule is a "Conflict Serializability" or "not a Conflict Serializability".
• Conflict Serializability


  Check conflict pairs in other transactions and draw the edge. A precedence graph is required to be created. A vertices is the collection of all the instructions of a Transaction Schedule. We will check the conflict pair on the same variable like R(x) - W(x). We will not check the conflict pair on different variable like R(x) - W(y). If no loop then we can say that it is a conflict Serializable schedule.
• View Serializability


  If no cycle is there then we rearrange the schedule and check if both are same processing wise.
• Why we need View Serializability? We know that a serial schedule never leaves the database in inconsistent state because there are no concurrent transactions execution. However a non-serial schedule can leave the database in inconsistent state because there are multiple transactions running concurrently. By checking that a given non-serial schedule is view serializable, we make sure that it is a consistent schedule.