标签：Control txn lock 09 locks concurrency schedules serializable
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
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。