1 / 22

Week-12a

Week-12a. Transactions, Properties of Transactions. What is transaction: . A transaction is the DBMS’s abstract view of a user program: a sequence of reads and writes. e.g ; The transfer of funds from one account to another is an example of transaction.

mikayla-booth
Download Presentation

Week-12a

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Week-12a Transactions, Properties of Transactions

  2. What is transaction: • A transactionis the DBMS’s abstract view of a user program: a sequence of reads and writes. • e.g; • The transfer of funds from one account to another is an example of transaction. • Transactions transform the database from one consistent state to another consistent state although the consistency may be violated during the transactions execution. • It is a grouped sequence of SQL statements • BEGIN TRANSACTION • starts a new transaction • COMMIT • ends a transaction by committing all changes • To the database • ROLLBACK • aborts a transaction and leaves the database • unchanged • initiated either explicitly by the program

  3. Properties of Transactions • There are four basic transaction properties • Atomicity: • This property also known as “all-or-nothing property” • Each transaction is said to be atomic if when one part of the transaction fails, the entire transaction fails and database state is left unchanged. • Atomicity means that users do not have to worry about the effect of incomplete transactions. • There are several reasons for transactions failure such as • Hardware failure: A disk drive fails, preventing some of the transaction's database changes from taking effect • System failure: The user loses their connection to the application before providing all necessary information • Database failure: e.g., the database runs out of space to save more data • Application failure: The application attempts to post data that violates a rule that the database itself enforces, such as attempting to create a new account without supplying an account number etc

  4. Consistency: • A transaction must transform the database from one consistent state to another consistent state. Or • The consistency of a transaction is simply its correctness. • It is the responsibility of both the DBMS and the application developer to ensure the consistency. • If a DBMS allows fields of a record to act as references to another record, then consistency implies the DBMS must enforce referential integrity: by the time any transaction ends, each and every reference in the database must be valid. If a transaction consisted of an attempt to delete a record referenced by another, each of the following mechanisms would maintain consistency. • Abort the transaction, rolling back to the consistent, prior state; • Delete all records that reference the deleted record (this is known as cascade delete); or, • Nullify the relevant fields in all records that point to the deleted record.

  5. Isolation: • Multiple transactions may execute concurrently. • But the system guarantee that for every transactions Ti and Tj, it appears to tj that either the Ti finished execution before Tj Started Or • Ti started execution after the Ti finished • So we can say that every transaction is unaware from the other transactions executing concurrently. • e.g: • Ti: Read(x) T2: Read(x) x,=x+1 x=x+1 Write(x) Write(x) Commit Commit So these transactions will execute in a sequence: Ti: Read(x) x,=x+1 Write(x) Commit T2: Read(x) x,=x+1 Write(x) Commit

  6. Durability • Durability is the DBMS's guarantee that once the user has been notified of a transaction's success, the transaction will not be lost. The transaction's data changes will survive system failure, and that all integrity constraints have been satisfied, so the DBMS won't need to reverse the transaction • A transaction is committed only after it is entered in the log.

  7. Week-12b Concurrency Controls, 2-PL,D2-PL, Time Stamping

  8. Concurrency Control • It means that managing the simultaneous access to a database. It prevents two users from editing the same record at the same time and is also concerned with serializing transactions for backup and recovery. • Concurrency Control Techniques: • There are two main concurrency control techniques those allow transactions to execute safely. Locking Methods: • The locking methods are the most widely used approach to handle concurrency in DBMS • If a transaction holds a the write lock on the data item, no other transaction can process or read or manipulate that data item. • A transaction continues to hold a lock until it uses the data and after the writing data it releases. • The most common locking is known as Two-Phase locking (2Pl)

  9. Two Phase Locking (2-PL): • According to the 2PL, a transaction handles its locks in two distinct, consecutive phases during the transaction's execution: • Expanding phase: locks are acquired and no locks are released. • Shrinking phase: locks are released and no locks are acquired. There are four Rules for transactions that follow 2PL • A transaction must acquire a lock on data object before performing any operation on it and all locks held by a transaction must be released when the transactions is completed. • Compatibility rules for locking are observed so no conflicting locks • After releasing any lock then other transaction can acquire that object or data. • All write locks released together when the transaction commits

  10. Distributed 2PL • It excepts the availability of lock managers at each site. If the database is not replicated, then the distributed 2PL degenerates into the primary copy 2PL Algorithm. • If the data is replicated the transaction implements the ROWA(Read Once and write available) Time stamp Methods: Time stamp: • A unique identifier created by the DBMS that indicates the relative starting of a transaction. Time stamping: • A concurrency control that is used to provide orders to transactions, in such a way where the older transactions, with smaller time stamps get priority in the if conflicts arises.

  11. These methods are different in concurrency control as compare to locking mechanism. • No locks are involved so no dead locks in centralized systems because timestamps generated by using the system clocks. • In DDBMS there is no such central system clock so each node has its own system clock and there no guarantee that these clocks are synchronized with each other. Time stamp follows the following two algorithm: Wait-Die Rule: • According to this rule if a Ti Requests a lock on a data item that is already locked by Tj, Ti is permitted to wait if a Ti is older than Tj. While if Ti is younger then Tj, then Ti will be aborted and restarted with the same timestamp. OR It Allows only an older transactions to wait for a younger one, otherwise the transaction is aborted(dies) and restarted with the same timestamp

  12. Wound-Wait Rule: • If Ti requests a lock on a data item that is already locked by Tj, than Ti is permitted to wait if it is younger than Tj, otherwise Tj will be aborted and all the locks will be granted to Ti. OR Only a younger transaction can wait for an older one. If an older transaction requests a lock held by a younger one the younger one is aborted.

  13. Week-12c Dead Locks

  14. Dead Locks • Any locking-based concurrency control algorithm my result the Dead-Locks • When some shared data is accessed and due to this the transaction may wait on locks. • A Dead-Locks can occur because transactions wait for on another. • Wait for graph (WFG) is a very helpful tool to analyzing Dead-Locks. • This graph show the wait for relationships among different transactions while the node of graphs show the concurrent transaction in the system. Ti Tj A WFG Example

  15. There are Three methods for dead lock handling: Dead Lock Prevention: • This method guarantee that dead locks can not occur in the first place. • Transaction manager checks transaction when it is first started and doesn't allow it to proceed if it may cause deadlock. • These type of systems are no very suitable for db environments • The basic problem is that it is usually difficult to know actually which data item will be accessed by a transaction. • Accessing of specific data item may depends on a conditions that may not be resolved until runtime

  16. Dead Lock Avoidance: • The simple way to avoid Dead-Locks is to order the resources & checks that each process request access to these resources. • The locks units in the DDBMs are placed in an order & transactions always request locks in that order. • But this ordering of Locks may be done locally or globally on different sites. • Dead Locks Detection and Resolution: • Dead-Locks Detection is very difficult in DDBMS Environment because several sites may involve in the transactions. • Global dea-locks can not be located or detected through the local information graph i.e; LWFG (Local wait for graph)

  17. There are three approached to detecting global dead-locks: • Centerlized: • One site is responsible for dead-lock detections for the entire system. • Hierarchical Dead-Lock Detection: • As compare to centralized this type of dead lock forma hierarchy in dead lock detectors. • In this each site maintain its own WFG, and send its local WFG to next level Dead lock detector.

  18. Distributed dead Lock detection • The method assign the responsibility of detecting dead locks on the individual Site bases. • The distributed dead lock detection algorithms need same changes at each site equally in the site mangers and in DD’s.

  19. Thanks

More Related