Presentation of practical exercise 4

1
Presentation of practical exercise 4

• Distributed deadlock detection

2
Transactions

• Familiar from database systems
• ACID properties
• Atomicity
• Consistency
• Isolation
• Durability
• Reviewed in chapter 12 of the book.

3
Locking

• Used to enforce serial equivalence (concurrency
  without sacrificing isolation)
• Two-phase locking used in this exercise
• A transaction has a growing phase in which it can
  set exclusive locks.
• A transaction has a shrinking phase in which it
  can release locks.
• This implies that a transaction cannot claim a
  lock after having released one.

4
Distributed databases

• A distributed database typically has its data
  objects distributed over different servers.
• Each server may provide services to applications
  and run transactions.
• The execution of the transaction may be performed
  by several servers in parallel.
• Not done in our exercise saves us from the need
  of an atomic commit protocol.

5
Deadlocks

• Informally, deadlocks occur when two or more
  transactions are waiting for each other.
• A transaction is waiting for another transaction
  if it is waiting for a lock held by that
  transaction.
• If the participants in the deadlock are located
  in different places, the deadlock is said to be
  distributed.
• Deadlocks are studied using wait-for graphs.

6
Wait-for graphs

• The nodes are transactions. An edge from node A
  to node B indicates that transaction A is waiting
  for transaction B.
• Cycles in the wait-for graph indicate deadlocks.

A
B
E
H
7
Deadlock detection

• Problem in distributed settings Noone knows the
  entire wait-for graph!
• Centralized solution A coordinator collects
  local wait-for graphs, combines them and looks
  for deadlocks.
• Distributed solutions
• Timeouts Easy to implement, hard to find good
  timeout interval. Detects false deadlocks.
• Edge chasing More complicated to implement, but
  works well.

8
Timeouts

• A transaction will only wait so long for a
  resource.
• If the wait takes too long, a deadlock is
  presumed to exist, and the transaction aborts.
• Waits can take a long time without deadlocks
  existing.
• Deadlocks take some time to be detected.
• The participants of a deadlock are not identified
  -gt only one transaction is eligible for abortion.

9
Edge chasing

• When a transaction starts waiting for a lock, a
  probe message is sent to the transaction
  currently holding the lock.
• When a transaction holding a lock receives a
  probe message, it forwards it to the transaction
  that it is waiting for, or discards the message
  if it isnt waiting for anyone.
• If a probe message returns to a transaction it
  has already visited, a cycle of waits has been
  found and a deadlock is presumed to exist.
• The deadlock may be phantom because a lock may
  have been released during the propagation of the
  probe message.

10
Edge chasing

• The transactions already visited by the probe
  message is kept in a list attached to the
  message.
• To detect deadlocks, it suffices to look for
  cycles in this list.
• A deadlock may be detected by any transaction.
• Any transaction in the cycle may be aborted to
  break the deadlock.

11
Edge chasing example

• Global wait-for graph

• Messages exchanged
• H initiates a probe
• H-gtE sent from H to E.
• E probes A
• H-gtE-gtA sent from E to A.
• A probes B
• H-gtE-gtA-gtB sent from A to B.
• B constructs this message
• H-gtE-gtA-gtB-gtE
• B detects the cycle E-gtA-gtB-gtE.
• B aborts or tells A or E to abort.

A
B
E
H
12
Our transaction system

• Abstract system consisting of servers, resources
  and transactions.
• Each server has a number of resources used by all
  transactions.
• Each server executes one transaction at a time.
• A transaction accesses 3-10 resources.
• Two-phase locking of resources is used to ensure
  isolation.

13
System overview
14
Distributed deadlock
Green arrows Resource is locked by this
transaction. Red arrows Transaction is waiting
for this resources lock. Solid arrows Part of
deadlock cycle.
15
Your task

• Implement timeouts and edge chasing in our
  distributed system.
• The system should use only one of the mechanisms
  at a time, but both should be implemented.
• Phantom deadlock detection is acceptable (and
  unavoidable).

16
Formal requirements

• Deliver a written report
• Refer to the compendium for details
• Demonstrate the program to one of the assistants.
• The exercise is compulsory, i.e., you must get
  Godkjent in order to take final exam.
• The exercise counts 25 of your final score!

17
Practical Exercise 4

• 25 of total grade.
• Due date 8pm Tuesday 27th April
• Late Submission Policy
• The penalty will be 20 for each day(maks.
  poengsum reduseres med 5 poeng/dag)
• Any submission after 8pm Thursday 29th April will
  not be accepted.
• Every group member gets the same grade.
• All group members must present at the
  demonstration.

18
Practical Exercise 4 Submission

• Demonstrate your program to the und.ass or
  stud.ass at the computer lab (22).
• Program testing
• Twenty two (22) test cases, 1 for each
  correctness test.
• Correctness
• No run-time error.
• Produces expected output.

19
Practical Exercise 4 Submission

• Writing report (hardcopy print-out Norsk,
  English) (3)
• Deliver to the assistants at the demonstration.
• What to include in the writing report?
• Short description (max 5 pages 2000 words) on
  program design.
• Program source code.
• Style and documentation.
• Test-case output files of 22 test cases.

20
Program Testing

• How to test your program
• Testing your program with the provided testing
  script and sample test cases (A-J).
• Study the test input-file and design more test
  cases by yourselves.
• Make sure your program work correctly in all
  possible scenarios.
• At the demonstration, your program will be tested
  with 22 test cases.

21
Example input test case

• TEST CASE A
• OUTPUT_FILE_PREFIX cases/output_test_case_A
• NOF_RESOURCES_PER_SERVER 10
• TIMEOUT_INTERVAL 0
• PROBING_ENABLED true
• Now come the transactions of this test case
• START TRANSACTION
• NUMBER OF ACCESSES 2
• ACCESS SERVER 1 RESOURCE 1
• PROCESS 100-100
• ACCESS SERVER 2 RESOURCE 1
• PROCESS 1000-1000
• END OF TRANSACTION
• WAIT 0-0
• END OF FILE

22
Example output test file

• Starting transaction 3003.
• Trying to claim lock of resource 9 at server 1
• Lock claimed. Processing...
• Trying to claim lock of resource 2 at server 4
• Lock claimed. Processing...
• Trying to claim lock of resource 4 at server 1
• Lock claimed. Processing...
• Trying to claim lock of resource 6 at server 3
• Lock claimed. Processing...
• Trying to claim lock of resource 4 at server 4
• Lock claimed. Processing...
• Committing transaction 3003.
• Unlocked resource 4 at server 4
• Unlocked resource 6 at server 3
• Unlocked resource 4 at server 1
• Unlocked resource 2 at server 4
• Unlocked resource 9 at server 1
• Transaction 3003 committed.

23
System GUI
Active transaction output
Output from this server
Local resources
List of all known servers
24
Program Testing Example

• Testing scenario for edge chasing algorithm (test
  case A).
• 4 servers, 10 resources at each server.
• Two transactions at each server
• S1 T1(R91,10000) 50 T2(R11,100), (R12,1000)
• S2 T1(R91,10) 50 T2(R12,100), (R13,1000)
• S3 T1(R91,10) 50 T2(R13,100), (R14,1000)
• S4 T1(R91,10) 50 T2(R14,100), (R11,1000)

25
Program Testing Example
Is deadlock occured? If there is deadlock, where?
26
Program Testing Example
Is deadlock occured for the first transaction at
each server?
27
Program Testing Example
Is deadlock occured for the second transaction
at each server? Possible.
Server 4
R0
R1
R2
R3

R9
S4 T2(R14,100), (R11,1000)
28
Program Testing Example

• What about time?
• Assume that all servers start at once, where is
  deadlock first detected?
• If each server starts 100ms after another, where
  is deadlock first detected?

29
S4 detect a deadlock. Which transaction will be
aborted?
30
Partial Solution vs New Program

• You can write your own program if you wish.
• If you decide to write a new simulation program,
  your program must follow the requirements and
  input-test-files.otherwise your test outputs
  will fail

31
Discussion Questions (next week)

• Newsgroup
• Send email
• Walk-in rm 243-IT bygget