vault backup: 2024-02-27 16:57:07

2024-02-27 16:57:07 +00:00
parent 489895a046
commit 8f7a395bdb
24 changed files with 614 additions and 30 deletions
--- a/Systems/Week
+++ b/Systems/Week
@@ -64,3 +64,38 @@ Similarly to the previous issue, we can solve this by locking T3 until the data
 - ![](Pasted%20image%2020240220132521.png)
 We can solve this issue by locking the data items appropriately. By write locking balx and balz in T5, T6 must wait to modify or read any data from either of these data items to preserve consistency.
 - ![](Pasted%20image%2020240220132550.png)
+
+# Tutorial
+
+1. .
+	1. Locks are used to preserve database consistency by disallowing reads and / or writes.
+	2. Locks are implemented by requiring transactions to request locks before reading or updating an item.
+	3. An exclusive lock is a write lock, restricting read and write access of the database item to the transaction that requested it.
+	4. An exclusive lock is granted if no other lock is currently in effect on a data item.
+2. .
+	1. False, a durable transaction is where all changes to data are persistent, even through power loss or system failure. The statement is an example of atomicity.
+	2. True
+	3. True
+	4. False, mutual blocking of data access in 2PL causes a deadlock
+3. .
+	1. .
+
+| Time | Transaction 1 | Transaction 2 | balance |
+| ---- | ---- | ---- | ---- |
+| t1 | begin |  | 100 |
+| t2 | read_lock( balance ) |  | 100 |
+| t3 | read( balance ) |  | 100 |
+| t4 | balance:=balance-60 | begin transaction | 40 |
+| t5 | … | wait | 40 |
+| t6 | abort, rollback. <br>Release lock ( balance ) | wait | 100 |
+| t7 |  | read_lock( balance ) | 100 |
+| t8 |  | read( balance ) | 100 |
+| t9 |  | balance:=balance-10 | 90 |
+| t10 |  | write( balance ) | 90 |
+| t11 |  | commit.<br>Release lock ( balance ) | 90 |
+
+# Laboratory
+1. ![](Pasted%20image%2020240223101502.png)
+2. ![](Pasted%20image%2020240223101441.png)
+3. ![](Pasted%20image%2020240223102417.png)
+4. ![](Pasted%20image%2020240223102717.png)
--- a/Systems/Week
+++ b/Systems/Week
@@ -0,0 +1,113 @@
+# Deadlock
+
+An impasse that may result when two or more transactions are waiting for locks held by the other to be released.
+ex. ![](Pasted%20image%2020240227130252.png)
+
+## Breaking a Deadlock
+
+Abort one or more transactions.
+If deadlock occurs, DBMS will
+
+- Automatically abort one transaction
+- Release locks, allow other transactions to continue
+- Restart aborted transaction
+
+## Handling Deadlock
+
+- Timeouts
+- Prevention
+- Detection and recovery
+
+### Timeouts
+
+Transactions that request a lock will only wait a system-defined amount of time.
+If lock not granted within the period,
+
+- Lock request times out
+- DBMS assumes deadlock
+- Transaction aborted and restarted
+
+### Prevention
+
+DBMS looks ahead to see if a transaction causes deadlock.
+Order transactions using transaction timestamps with the following methods:
+
+#### Wait-Die
+
+Only older transaction can wait for a younger one.
+If a younger transaction requests a lock held by an older one, the younger one is aborted then restarted with the same timestamp, so will eventually become the oldest active transaction and will not die.
+![](Pasted%20image%2020240227131306.png)
+
+#### Wound-Wait
+
+If an older transaction requests a lock held by a younger one, the younger one is aborted.
+![](Pasted%20image%2020240227131321.png)
+
+#### Summary of Prevention Techniques
+
+Deadlock free
+Wait-Die, transactions only wait for younger transactions, no cycle
+Wound-Wait, transactions only wait for older transactions, no cycle
+Both may cause transactions to be aborted and restarted needlessly, even if they would not cause a deadlock.
+
+### Deadlock Prevention and Recovery
+
+DBMS allows deadlock to occur, recognises and breaks it.
+DBMS uses a wait-for-graph (WFG) that shows transaction dependencies
+A WFG is generated by creating a node for each transaction, and an edge ( Ti -> Tj ). If Ti is waiting to lock an item locked by Tj.
+Deadlock exists if the WFG contains a cycle.
+A WFG is created at regular intervals
+
+#### Wait-For-Graph Example 1
+
+![](Pasted%20image%2020240227131936.png)
+![](Pasted%20image%2020240227131954.png)
+![](Pasted%20image%2020240227132007.png)
+
+#### Example 2
+
+![](Pasted%20image%2020240227132741.png)
+Edge Ti -> Tj, if Ti waiting to lock item locked by Tj
+![](Pasted%20image%2020240227132816.png)
+Since the WFG contains a cycle, deadlock exists.
+
+#### Example 3
+
+![](Pasted%20image%2020240227133521.png)
+
+- ![](Pasted%20image%2020240227133544.png)
+Graph contains several cycles, deadlock exists
+
+#### Recovery
+
+Several issues that DBMS needs to address
+
+- Selecting deadlock victim that will minimise cost of breaking deadlock
+	- May be better to abort transaction that has just started, rather than one that has been running longer.
+	- May be better to abort transaction that makes little change to database, rather than one that makes a significant change
+- Avoiding starvation
+	- Occurs when same transaction is chosen as victim, preventing completion
+	- DBMS may try to avoid this by storing a count of abortions of a transaction.
+
+# Tutorial
+
+1. .
+	1. Deadlock occurs when one or more transactions are held by each other, and neither can continue
+	2. The DBMS detects deadlock by utilising a WFG, and checking for cycles
+	3. The only way to break a deadlock is by aborting one or more transaction.
+2. .
+
+| Transaction | Locked | Waiting For |
+| ----------- | ------ | ----------- |
+| T1          | X      |             |
+| T2          | Z      |             |
+| T3          |        | Z           |
+![](Pasted%20image%2020240227161426.png)
+
+3. ![](Pasted%20image%2020240227161946.png)
+There is no deadlock since there are no cycles.
+
+4. ![](Pasted%20image%2020240227162324.png)
+There may be a deadlock, since there are multiple cycles in the WFG
+
+# Database Recovery Part 1