Concurrency Control

Objectives Management of Databases Concurrency Control Database Recovery Database Security Database Administration

Transactions ACID – Atomic, Consistent, Isolation, Durable Transactions – completely succeed or completely fail

ACID attributes Atomic – Group one or more changes into an all or nothing operation Consistency – during a transaction it may violate integrity rules, but no other transaction can see it and it eliminated before ending Isolation- Appear that transaction is running by itself (invisible to all other) Durability – once commited, changes persists even in event of system failure

Database Design issues Because of simultaneous updates consider: Concurrency Control – mechanism to apply ACID attributes to transactions Transaction Security

Lost Update Anomaly

Inconsistent retrieval anomaly

Database Design Issues Lost updates Inconsistent reads

DBMS components Transactions Transaction Manager Data Manager Data

Operations for Transactions Read – read value of X Write – write new value of X Begin – start of a private workspace for transaction End – end of transaction and attempt to transfer information from private workspace to database

Two Phase Commit The movement of transaction data from private workspace to stored database First Phase – try writing private workspace to a secure storage (not the stored DB). If OK then go to 2nd phase, otherwise lose changes but no harm done to DB. Second Phase – data is moved from private workspace to stored database. If anything happens, the DB can recover from values in secure storage.

Control Scheme – sharing fields Pessimistic scheme – at least two users going for same resource, one gets there first and locks the object until they are done. Optimistic scheme – use when likely one user will access field at a time. At transaction commit, make sure one has accessed the field since your transaction began via timestamp.

Control Scheme Goal Purpose of both types is DB in consistent state after transactions. To achieve consistent state, transactions must behave as performing one after another – serializability Locks are one method to enforce serializability to concurrent transactions

Database recovery Consistency – return state of DB after a failure (ACID) Failure – what kinds of failure to anticipate Transaction – atomic (succeed or fail)

Database Failures Transaction failures – DB intact Various reason a transaction fails User aborts DBMS aborts because of deadlock System failures (main memory lost) Bug in DBMS OS fault Hardware fault Media failure (previous content lost) Bug in OS Hardware errors in channel or disk controller Head crash Magnetic decay

Recovery actions Depends on type of failure Transaction and system failures – previous content intact then use log files that contain the latest changes to the last consistent state of DB Media failure – recover with a redundant copy of the database

Direct Page and Indirect Page