Lecture 09 Concurrency Control Part II (including 2-phase lock)
作者：互联网
Overview:
A database must provide a mechanism that will ensure that all possible schedules are
·either conflict or view serializable, and
·are recoverable and preferably cascadeless
Schedules must be conflict or view serializable, and recoverable, for the sake of database consistency, and preferably cascadeless.
A policy in which only one transaction can execute at a time generates serial schedules, but provides a poor degree of concurrency.
Concurrency-control schemes tradeoff between the amount of concurrency they allow and the amount of overhead that they incur.
Some schemes allow only conflict-serializable schedules to be generated, while others allow view-serializable schedules that are not conflict-serializable.
We are only going to study conflict-serializability.
Concurrency Control vs. Serializability Tests:
Concurrency-control protocols allow concurrent schedules, but ensure that the schedules are conflict/view serializable, and are recoverable and cascadeless .
Concurrency control protocols generally do not examine the precedence graph as it is being created
Different concurrency control protocols provide different tradeoffs between the amount of concurrency they allow and the amount of overhead that they incur.
Tests for serializability help us understand why a concurrency control protocol is correct.
MECHANISMS FOR ENSURING ISOLATION OF TRANSACTIONS：
Users submit txns, and each txn executes as if it was running by itself.
→ Easier programming model to reason about.
But the DBMS achieves concurrency by interleaving the actions (reads/writes of DB objects) of txns.
We need a way to interleave txns but still make it appear as if they ran one-at-a-time.
A concurrency control protocol is how the DBMS decides the proper interleaving of operations from multiple transactions.
Two categories of protocols:
→ Pessimistic: Don’t let problems arise in the first place.
→ Optimistic: Assume conflicts are rare, deal with them
after they happen.
Example of both good and bad INTERLEAVING EXAMPLE:
FORMAL PROPERTIES OF SCHEDULES:
Given these conflicts, we now can understand
what it means for a schedule to be serializable.
→ This is to check whether schedules are correct.
→ This is not how to generate a correct schedule.
An example of the threesome schedule:
We need a way to guarantee that all execution schedules are correct (i.e., serializable) without knowing the entire schedule ahead of time.
Solution: Use locks to protect database objects.
EXECUTING WITH LOCKS:
BASIC LOCK TYPES:
S-LOCK: Shared locks for reads.
X-LOCK: Exclusive locks for writes.
EXECUTING WITH LOCKS:
Transactions request locks (or upgrades). Lock manager grants or blocks requests. Transactions release locks.
Lock manager updates its internal lock-table.
→ It keeps track of what transactions hold what locks and
what transactions are waiting to acquire any locks.
CONCURRENCY CONTROL PROTOCOL:
Two-phase locking (2PL) is a concurrency control protocol that determines whether a txn can access an object in the database on the fly.
The protocol does not need to know all the queries that a txn will execute ahead of time.
TWO-PHASE LOCKING:
Phase #1: Growing
→ Each txn requests the locks that it needs from the DBMS’s lock manager.
→ The lock manager grants/denies lock requests.
Phase #2: Shrinking
→ The txn is allowed to only release locks that it previously acquired. It cannot acquire new locks.
2PL on its own is sufficient to guarantee conflict serializability.
→ It generates schedules whose precedence graph is acyclic. But it is subject to cascading aborts.
2PL: CASCADING ABORTS:
STRONG STRICT TWO-PHASE LOCKING：
The txn is not allowed to acquire/upgrade locks after the growing phase finishes.
Allows only conflict serializable schedules, but it is often stronger than needed for some apps.
A schedule is strict if a value written by a txn is not read or overwritten by other txns until that txn finishes.
Examples:
2PL DEADLOCKS:
A deadlock is a cycle of transactions waiting for locks to be released by each other.
Two ways of dealing with deadlocks:
→ Approach #1: Deadlock Detection
→ Approach #2: Deadlock Prevention
DEADLOCK DETECTION:
The DBMS creates a waits-for graph to keep
track of what locks each txn is waiting to acquire: → Nodes are transactions
→ Edge from Ti to Tj if Ti is waiting for Tj to release a lock.
The system periodically checks for cycles in waits- for graph and then decides how to break it.
DEADLOCK HANDLING:
When the DBMS detects a deadlock, it will select a "victim" txn to rollback to break the cycle.
The victim txn will either restart or abort(more common) depending on how it was invoked.
There is a trade-off between the frequency of checking for deadlocks and how long txns have to wait before deadlocks are broken.
Selecting the proper victim depends on a lot of
different variables....
→ By age (lowest timestamp)
→ By progress (least/most queries executed)
→ By the # of items already locked
→ By the # of txns that we have to rollback with it
We also should consider the # of times a txn has been restarted in the past to prevent starvation.
After selecting a victim txn to abort, the DBMS can also decide on how far to rollback the txn's changes.
Approach #1: Completely
Approach #2: Minimally
DEADLOCK PREVENTION:
When a txn tries to acquire a lock that is held by another txn, the DBMS kills one of them to prevent a deadlock.
This approach does not require a waits-for graph or detection algorithm.
Assign priorities based on timestamps:
→ Older Timestamp = Higher Priority (e.g., T1 > T2)
Wait-Die ("Old Waits for Young")
→ If requesting txn has higher priority than holding txn, then requesting txn waits for holding txn.
→ Otherwise requesting txn aborts.
Wound-Wait ("Young Waits for Old")
→ If requesting txn has higher priority than holding txn, then holding txn aborts and releases lock.
→ Otherwise requesting txn waits.
Why do these schemes guarantee no deadlocks?
Only one "type" of direction allowed when waiting for a lock.
When a txn restarts, what is its (new) priority?
Its original timestamp. Why?
标签：Control,txn,lock,09,locks,concurrency,schedules,serializable 来源： https://www.cnblogs.com/M1stF0rest/p/16411133.html