Download Concurrency Control - High Point University

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Business intelligence wikipedia , lookup

Data vault modeling wikipedia , lookup

Entity–attribute–value model wikipedia , lookup

Operational transformation wikipedia , lookup

Relational model wikipedia , lookup

Global serializability wikipedia , lookup

Database wikipedia , lookup

Database model wikipedia , lookup

Clusterpoint wikipedia , lookup

Commitment ordering wikipedia , lookup

Versant Object Database wikipedia , lookup

Expense and cost recovery system (ECRS) wikipedia , lookup

Serializability wikipedia , lookup

Concurrency control wikipedia , lookup

Transcript
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
1. 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.
2. 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