1 / 31

Transactions

Transactions. Definition . Transaction is a set of instructions or operations that perform a logical function. Transa ction model. Satu State konsisten. Satu State konsisten. Satu State inkonsisten. Eksekusi Transaksi Ti. Mulai Transaksi Ti. Akhir Transaksi Ti.

bell
Télécharger la présentation

Transactions

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. Transactions

  2. Definition  • Transaction is a set of instructions or operations that perform a logical function.

  3. Transaction model Satu State konsisten Satu State konsisten Satu State inkonsisten EksekusiTransaksi Ti MulaiTransaksi Ti AkhirTransaksi Ti • When transaction system can be in an inconsistent state, but in the end systems in a consistent state again. Transactions never left the state in an inconsistent state

  4. Transaction goal • concurrent • Failure handling

  5. Feature Transaction  • A tomicity • C onsistent • I solated • D urable • (ACID)

  6. Atomicity • ach transaction can not be in for • "All or nothing deal" • If the transaction fails, the system responsible for the failure recovery

  7. Atomicity • Examples in the case of money transfers between accounts. will be conducted at least two operations, namely • debit on the sender's account • credit on the recipient's account. • Each of these operations must be executed to keep the overall data on the recipient and sender of money consistently.

  8. Consistency • Consistency is the truth of the system transactions. • A transaction that actually change the system from one consistent state into another consistent state

  9. Isolation • A separate transaction with each other. • Unfinished transactions can not show the results to other transactions before the transaction commit.

  10. Durability • When a transaction commits, the system will guarantee the results of operations will continue.

  11. With the nature of atomicity, a transaction can be executed as a whole certainly • if there is system crash all data that has been modified by the transaction is returned to the initial state. • Consistent initial state will be changed into another state which is also consistent after a transaction has executed successfully. • With the nature of isolation can also be said of each scheduleisSerializable, which will be discussed in the serialization. Every time a transaction has been successfully implemented will be guaranteed that the result of data updates will be maintained.

  12. Concurrent handling • Transaction is a unit of consistency (feature) • Transactions can walk one by one in sequence.But less efficient. • Full competition aims to optimize the system while maintaining the consistency of the system with a high degree of competition

  13. Serializability • Criteria truth competition control algorithm. • Results Parallel = serial

  14. Full lock-based concurrence • One way of ensuring serializability is a data access mutex = locking. • Mode lock • Shared lock • Exclusive lock

  15. Shared lock / read lock • If a transaction Ti is doing shared-mode lock on the data Q, the transaction will be able to read operations on the Q but can not perform write operations on the Q

  16. Exclusive Lock • If a transaction Ti is doing exclusive-mode lock on the data Q, then the transaction can read and write on the Q. • Other transactions can not lock any of the objects that have been in the exclusive lock

  17. Q data access of a transaction Ti • Q Check if the data is locked by another transaction. If not, Ti can directly access the Q, if yes, Ti must wait (wait). • If the desired lock mode is exclusive-lock mode, then Ti must wait until the Q data was released. • If the desired lock mode is shared-lock mode, then Ti must wait until the data is not in Q-mode exclusive lock by other data. In this case Q data can be accessed when in idle mode or shared-lock.

  18. Two-phase LockingProtocol • Growing phase • Phase in which a transaction may only do locking on the data. In this phase, the transaction may not release the other data. • Shrinking phase • Phase in which a transaction to release the data. In this phase, the transaction may not lock on other data.

  19. Two-phase LockingProtocol • Two-phase locking protocol widely used to maintain the properties of a schedulingSerializable, but this protocol can not guarantee that deadlock will not occur because there are still transactions in the state of waiting (wait ()).

  20. Full competition with ordering time (timestamp) • Not manage to serializabiltymutex but with the time line. • Property timestamp • Uniquness • Unique, different from one another • Monotonicity • Timestamp value increases monotonically

  21. TimeStamp Rules O ij is executed before O kl if and only if Timestamp (Ti) < Timestamp(Tk),  T i is a transaction older than T k.

  22. Memory • Memory is divided into three: • The main memory (volatile memory) • Secondary storage (memory nonVolatile) • Storage stability (stable storage)

  23. Memory • Main Memory • Information on the main memory can not survive when the crashoccurred on the system. Quick access • Secondary Storage • Information can survive in the event of system crashes.

  24. Memory • Storage Stable (Stable storage) • Information on these storage small chance to lose. • Implementation is done by replication of information on some secondary storage (mirroring)

  25. Recovery  • Recovery of the event cancellation of the transaction (abort recovery) • Recovery of menglami system crash (crash recovery) • Terhadapa recovery storage media failure(media recovery)

  26. Abort recovery • Update = read and modify the system • Read = just read the system • Commit = makes all modifications to the system to be permanent • Abort = cancel action has been done • Approachupdate-in-place • Defferred-update approach

  27. Update-in-Place • Update -rekord undo record in the log file • Read - read the value of objects in the system • Commit - ignoring the log file undo • Abort -rekord use undo to restore the system to its original state.

  28. Deffered-Update • Update - recording a redo record in redo log file • Read - combining redo log files and system for determining the value of the object • Commit - update the system by applying the redo log files • Abort - ignore the redo log files

More Related