250 likes | 622 Views
transactions and concurrency control. Sadhna Kumari. OUTLINE. ACID Properties 2-Phase Commit Protocol TPS Serializability Concurrency Control Protocols Current Research Future References. ACID PROPERTIES. Atomicity: A transaction is either performed entirely or not at all.
E N D
transactions and concurrency control Sadhna Kumari
OUTLINE • ACID Properties • 2-Phase Commit Protocol • TPS • Serializability • Concurrency Control Protocols • Current Research • Future • References
ACID PROPERTIES • Atomicity: A transaction is either performed entirely or not at all. • Consistency: After execution of a transaction, the database must be in correct state. • Isolation: Partial results of an incomplete transaction are not visible to others. • Durability: The results of a committed transaction must be made permanent.
2-PHASE COMMIT PROTOCOL Coordinator - pre-commit the transaction - sends request to all participants - collects all replies - if all replies are YES then commit and send COMMIT else abort and send ABORT - receives response Participant - receives pre-commit message - if ready then pre-commits and replies YES else aborts transaction and replies NO - receives decision - if commit then COMMIT, if abort then ABORT - send response
serializability • Serial Schedule: serial execution of actions of set of transactions • Serializable schedule: Execution result is equivalent to that of serial schedule • Conflicts: write-write, read-write or write-read • Serializability ensures consistency
serializability (example) • Serial schedule : {t1,t2}, {t2,t1} t0 COMMITED • Possible results {C,D} : {80,120}, {120,80} • Operation pairs {1,3} & {2,4} – write-write conflict
two phase locking • Expanding phase: new locks on items can be acquired but none can be released • Shrinking phase: existing locks can be released but no new ones can be acquired • Problems: • Deadlock • Rolling aborts • Commit dependence • Strict two phase locking: only release locks either at commit or at abort
timestamp ordering • Each transaction has a Timestamp(TS) associated with it. • TS is not necessarily real time, can be a logical counter • TS is unique for a transaction • New transaction has larger TS than older transaction • Larger TS transactions wait for smaller TS transactions and smaller TS transactions die and restart when confronting larger TS transactions • No deadlock
optimistic concurrency control • Allows entire transaction to complete and then validate the transaction before making its effect permanent • Execution Phase: Starts with begin transaction and ends with end transaction • Validation Phase: Coordinator TM with participant TMs validate the consistency using two-phase validation protocol • Update Phase: Update must be committed for validated transaction
COMPARISON • 2PL is the most popular choice because it is simple • 2PL is a pessimistic protocol because it achieves serializability by restricting the operation in a transaction • Timestamp ordering is less pessimistic, allows operations to execute freely • Optimistic concurrency control ignores conflicts during execution, but requires very elaborate validation
distributed lock manager (GFS) • Locking responsibility is distributed • Partitioning the lock space (can be done by using hash function ) • Faster processing than centralized approach • Avoid single point failure • Deadlock detection is complicated
concurrency control in real-time [4] • Each transaction is associated with a priority, high priority transaction has earlier deadline • Higher priority transaction obtains the lock first. Lower priority transaction has to sacrifice the lock. • If transaction confronts the same priority transaction, then lock is obtained by timestamp ordering
Currently concurrency control mechanism are mostly at OS/Kernel level. With increasing parallel computing, user level locking mechanism should be made available • Small locking object is ideal for concurrency control. It is always better to lock attribute than whole file • Need for a standardized concurrency control protocol for distributed/parallel environment
references [1] Distributed Operating Systems & Algorithms, Andy Chow & Theodore Johnson,1997 [2]http://en.wikipedia.org/wiki/Concurrency_control [3] Sungchune Choi ; Minseuk Choi ; Chunkyeong Lee ; Hee Yong Youn ; “Distributed Lock Manager for Distributed File System in Shared-Disk Environment” Sep 2010 [4] QianshengZheng ; Xiaoming Bi ; “An improved concurrency control algorithm for distributed real-time database” Aug 2010 [5] http://en.wikipedia.org/wiki/Distributed_file_system