TRANSACTIONS AND CONCURRENCY CONTROL

Sadhna Kumari

OUTLINEACID Properties2-Phase Commit ProtocolTPSSerializabilityConcurrency Control ProtocolsCurrent ResearchFutureReferences

ACID PROPERTIESAtomicity: 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 PROTOCOLParticipant

- 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

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

DISTRIBUTED TRANSACTION PROCESSING SYSTEM

DISTRIBUTED TRANSACTION PROCESSING SYSTEM (CONTD)

SERIALIZABILITYSerial Schedule: serial execution of

actions of set of transactionsSerializable schedule: Execution result is

equivalent to that of serial scheduleConflicts: write-write, read-write or

write-readSerializability ensures consistency

SERIALIZABILITY (EXAMPLE)

Serial schedule : {t1,t2}, {t2,t1} t0 COMMITEDPossible results {C,D} : {80,120}, {120,80}Operation pairs {1,3} & {2,4} – write-write

conflict

INTERLEAVING SCHEDULES

TWO PHASE LOCKINGExpanding phase: new locks on items can be

acquired but none can be releasedShrinking phase: existing locks can be

released but no new ones can be acquiredProblems:

Deadlock Rolling aborts Commit dependence

Strict two phase locking: only release locks either at commit or at abort

TIMESTAMP ORDERINGEach transaction has a Timestamp(TS)

associated with it.TS is not necessarily real time, can be a logical

counterTS is unique for a transactionNew transaction has larger TS than older

transactionLarger 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

COMPARISON2PL is the most popular choice because it is

simple2PL 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

CURRENT RESEARCH

DISTRIBUTED LOCK MANAGER[3]

DISTRIBUTED LOCK MANAGER (GFS)

Locking responsibility is distributedPartitioning the lock space (can be done by

using hash function )Faster processing than centralized approachAvoid single point failureDeadlock 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

FUTURE

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] Qiansheng Zheng ; Xiaoming Bi ; “An improved concurrency control algorithm for distributed real-time database” Aug 2010

[5] http://en.wikipedia.org/wiki/Distributed_file_system

THANK YOU