SWIFT Presentation

SWIFT
A Real Time Commit Protocol
Dr. Udai Shanker

Department of Computer Science & Engineering M. M. M. Engineering College, Gorakhpur-273 010 India
1
Dept. of CSE, MMMEC Gorakhpur
Outline of Presentation
Distributed Real Time Database Systems (DRTDBS) - A Glance
Performance Issues DRTDBS Model Commit Protocol - SWIFT Conclusions Scope for Future Research Questions & Answers
DRTDBS A Glance
Real Time System
Results be produced within a specified deadline period.
Correctness depends on

Logical results of computation, and also Time at which results will be produced
Distributed Database System

A Collection of Data Items Distributed over Distant Locations
DRTDBS
A Join of Real Time Systems & Distributed Database Systems

Time Constrained Distributed Database Systems
DRTDBS A Glance
Real Time Systems vs. DRTDBS Real Time Systems
Task Centric Deadlines attached to tasks.
contd
Distributed Real Time Databases

Data Centric Data has temporal validity, i.e., deadline attached to transactions. Transactions must be executed by deadlines to keep the data valid, in addition to produce results in a timely manner.
DRTDBS A Glance
Real-Time,DBs
Multimedia DB
Archival DBs World Wide Network News Services Need Summary Report by 4 PM Satellite Imagery The Problem Scenario
contd
Troop Positions
DRTDBS A Glance
Transactions
Perform task of setting the value of a real world object. Are invoked to access databases by all applications. Must be scheduled to complete within their time constraint. Satisfy database constraints.
contd
Notion of Transaction
Partially ordered set of database operations A complete and consistent computation (i.e., they are designed to terminate correctly, leaving the database in a consistent state) Have dynamic runtime behavior (dependent on the state of the database, i.e., data values) Data is a resource (transaction can be blocked in accessing data objects) A transaction is said to commit if all changes can be successfully made to the database and to abort if all changes cannot be successfully made to the database.
DRTDBS A Glance
Hard Real Time Transactions
v(t)
contd
Hard deadline
v0
If deadline missed, catastrophic consequence, either heavy economic or human safety critical applications life or environment threatening emergency situations
7
DRTDBS A Glance
Firm Real Time Transactions
v(t)
contd
firm deadline
v0
If deadline missed Completing the transaction may generate harmful effects on the system. It can be, however late result is worthless. ExpTransactions attempting to recognize a moving object. Arbitrage trading. 8
DRTDBS A Glance
Soft Real Time Transactions
If deadline missed
Some value even after expiry of its deadlines Value diminishes with time
contd
v(t)
v0
Soft deadline
d1
d2
DRTDBS A Glance
Types of Transaction (Operations)
Write-only Transactions (Sensor Updates): environment and write into the database
contd
Obtain state of the
Store sensor data in database (e.g., temperature) Monitoring of environment Ensure absolute temporal consistency
Update Transactions (Application Updates) Derive new data and store in database Based on sensor and other derived data Read-only Transactions
Read data, compute, and report (or send to actuators)
10
Performance Issues
Performance Issues
Transaction Scheduling
Conflict Resolution Execute Execute Conflict - Concurrency Control Execute Commit Conflict - Commit Procedure Deadlocks Priority Assignment Policy Data Invariance
Data Access Mechanism

Static Two Phase Locking Dynamic Two Phase Locking
11
Performance Issues
I/O & Disk Scheduling Buffer Management
contd
Communication Delays between Different Sites

Site Failures Checkpointing and Logging for the Fault Tolerance & Failure Recovery Predictability & Consistency Security CPU Scheduling
12
DRTDBS Model
Transaction Manager Transaction Generator Sink
ready queue Priority Assignment
Terminate Abort Commit C.C.Manager
wait Queue Database Operation
Blocked Computation Memory
Site 1 Network Manager Site 3
Site 2
Site N
13
DRTDBS Model
Model Assumptions
Firm Real Time Transactions
contd
Processing of a transaction requires use of CPU and data items located at local site or remote site. Arrivals of transactions at a site are independent of the arrivals at other sites and use Poisson distribution. Each cohort makes read and update accesses. Each transaction pre-declares its read-set (set of data items that the transaction will only read) and update-set (set of data items that the transaction will update). Static two phase locking with higher priority scheme is used for locking the data items.
14
DRTDBS Model
contd
A lending transaction cannot lend the same data item in read/update mode to more than one cohort.
Cohort already in the dependency set of another cohort cannot permit another incoming cohort to read or update.
Database is in main memory or in disk at all sites. Communication delay is considered either 0ms or 100ms.
In case of disk resident database, buffer space is sufficiently large to allow the retention of data updates until commit time.
Cohorts are executed in parallel way. Operations performed by one cohort are independent of the results of the operations performed at the other sites.
15
DRTDBS Model
Symbols
mi
contd
Meaning
No. of Cohorts of ith Transaction No. of Operations in Local Cohort of Ti No. of Operations in jth Cohort of Ti Time Required to Lock/Unlock a Data Item Time to Process a Data Item (Assuming read operation takes same amount of time as write operation.) No. of Messages Exchanged Between Coordinator and a Cohort Communication Delay, i.e., Constant Time Estimated for a Message Going from One Site to Another Number of Local Operations Max. No. of Remote Operations Taken Over by All Cohorts
Nilocal
Ni j
Tlock Tprocess Ncomm Tcom Noper_local Noper_remote 16
DRTDBS Model
Proposed Method for Computation of Deadline
Deadlines - Expected Execution Times Deadline (Di) of Transaction (Ti): Di=Ai+ SF *Ri
contd
Ai - Arrival Time of Transaction (Ti) at A Site SF - Slack Factor Ri - Minimum Transaction Response Time Given as
Ri =Rp+Rc Rp - Time for Execution Phase Rc- Time for Commitment Phase
17
DRTDBS Model
Global Transactions
contd
Rp = max{Tlp Nilocal ,max(Tlp Nij ) + 2Tcom }

1 j mi
j local
Tl p 2 Tlock Tprocessin g
R c = N comm Tcom
Local Transactions
R p = (2 Tlock + Tprocess ) N oper_local
Rc = 0
18
DRTDBS Model
Simulation Details
Event driven simulator was written in C language.
contd
Each result was calculated as an average of 10 independent runs. In each run, 20000 transactions were initiated. Primary Performance Criteria Proportion of Missed Deadlines (Miss Percentage, MP)
MP = number of transactio ns aborted transactio ns submitted to the system for 100
no.
of
proces sin g
Miss Percentage Values Normal Load - 0 to 20% Heavy Load - 20% to 100%
19
DRTDBS Model
Two Simulation Models
contd
Main Memory as well as Disk Resident Distributed Real Time Database System Structure of simulation model and method for computation of deadlines of global & local transactions are same as described previously Each transaction is associated with Health factor (HF) = TimeLeft/ MinTime Where, TimeLeft - Time left until Transactions Deadline MinTime - Minimum Time required for Commit Processing MinHF 1. Threshold that allows data held by committing transaction to be accessed 2. Taken as 1.2 (Value of MinHF used in PROMPT)
20
DRTDBS Model
Simulation Parameters
Parameters Nsite AR Tcom SF Noper PageCPU PageDisk DBsize Meaning Number of Site Arrival Rate Communication Delay Slack Factor No. of Operations in a Transaction CPU Page Processing Time Disk Page Processing Time Database Size Settings 4
contd
2-20 Transactions/Second 100 ms or 0 ms (Constant) 1-4 (Uniform Distribution) 3-20 (Uniform Distribution) 5 ms 20 ms 200 Data Items/Site
Pwrite
21
Write Operation Probability
0.60
Commit Protocol
Introduction
Several factors contribute to difficulty in meeting real time constraint.
Data Conflicts Among Transactions Prime Factor for System Performance Degradation Data Conflicts Between Two Transactions Execute-Execute Conflicts-Already Addressed Execute-Commit Conflicts-Very Little Work Designing of a Good Commit Protocol - Important for DRTDBS
SWIFT
Static Two Phase Locking with Higher Priority Based, WriteUpdate Type, Ideal for Fast and Timeliness Commit Protocol
22
Commit Protocol
Related Work
contd
Two Phase Commit (2PC) is still one of the most commonly used protocols in the study of DRTDBS
N. Soparkar, E. Levy, H.F.Korth and A. Silberschatz. Adaptive Commitment for Real-time Distributed Transaction. Technical Report TR-92-15, Department of Computer Science, University of Texax, Austin, 1992. K.Y. Lam, C-L. Pang, S.H. Son and J. Cao. Resolving executing-committing conflicts in distributed real-time database systems. The computer Journal, 42 (8), 1999, 674-692. J. Haritsa, K. Ramamritham and R. Gupta. The PROMPT real time commit protocol. IEEE Transaction on parallel and distributed systems, 11(2), 2000, 160-181. Biao Qin and Yunsheng Liu. High performance distributed real time commit protocol, Journal of Systems and Software, Elsevier Science Inc, 2003, 1-8.
23
Commit Protocol
User
contd
Transaction Arrival
Coordinator Site
Cohort Site i
Cohort site j
Cohort site k
Cohort Site n
Commit Protocol Transaction Commit
24
Commit Phase
All Cohorts Processed
Execution Phase
Commit Protocol
contd
Two-Phase Commit (2PC): Presumed Nothing 2PC protocol (PrN)

Assuming no failures, it works as follows: Site at which transaction originates is coordinator; Other sites as well as coordinator site, at which it executes, creates cohorts. When an transaction wants to commit: Coordinator sends prepare msg to each cohort. Cohort force-writes an abort or prepare log record and then sends a no or yes msg to coordinator. If coordinator gets unanimous yes votes, force-writes a commit log record and sends commit msg to all cohorts. Else, force-writes abort log rec, and sends abort msg. Cohorts force-write abort/committed log rec based on msg they get, then send ack msg to coordinator. Coordinator writes end log rec after getting all acks.
Coordinator
Commit Protocol
Cohort
Prepare Log Prepared
contd
Vote YES
Log Commit Commit
Ack Log END
Log Committed
26
Log record is forced written
Two Phase Commit (2PC) Protocol

Decision Phase
Voting Phase
Commit Protocol-SWIFT
Proposed Real Time Commit Protocol - SWIFT
Data Access Conflicts Resolving Strategies
Types of Dependencies (Update Model & Read only) Commit Dependency (CD) If a transaction T2 updates a data item read by another transaction T1, a commit dependency is created from T2 to T1. Here, T2 is not allowed to commit until T1 commits. Abort Dependency (AD) If transaction T2 reads or updates an uncommitted data item written by transaction T1, an abort dependency is created from T2 to T1. T2 aborts, if T1 aborts and T2 is not allowed to commit before T1. Each transaction Ti, that lends its data while in PREPARED state to an executing transaction, maintains two sets CDS (Ti): Set of Transactions (Tj) commit dependent on transaction (Ti) ADS (Ti): Set of transactions (Tj) abort dependent on transaction (Ti) 27
contd
Type of Dependencies in Different Cases of Data Conflict Three Possible Cases of Conflicts
Case 1: Read-Update Conflict. If transaction T2 requests an update-lock while transaction T1 is holding a read-lock, a commit dependency is defined from T2 to T1. First, the transaction identity (id) of T2 is added to the CDS (T1). Then T2 acquires the update-lock.
Case 2: Update-Update Conflict. If both locks are update-locks and HF(T1) MinHF, an abort dependency is defined from transaction T2 to transaction T1. The transaction identity (id) of T2 is added to ADS (T1), and T2 acquires the update-lock; otherwise, T2 is blocked. Case 3: Update-Read Conflict If transaction T2 requests a read-lock while transaction T1 is holding an update-lock and HF(T1) MinHF, an abort dependency is defined from T2 to T1. The transaction identity (id) of T2 is added to ADS (T1), and T2 acquires the read-lock; otherwise, T2 is blocked. 28
contd
Processing of Access of Data Items in Conflicting Mode by Lock Manager

If (T2 CD T1) { CDS (T1) = CDS (T1) {T2}; T2 is granted update lock; } else { if ((T2 AD T1) AND (HF(T1) MinHF)) { ADS (T1) = ADS (T1) {T2}; T2 is granted the requested lock (read or update); } else T2 will be blocked; }
29
Mechanics of Interaction Borrower Cohorts between Lender
contd
and
If transaction T2 has borrowed the data item locked by transaction T1, following three scenarios are possible:
Scenario 1: T1 receives decision before T2 is going to start processing phase after getting all its locks. If the global decision is to commit, T1 commits. All cohorts in ADS (T1) and CDS (T1) will execute as usual and the sets ADS (T1) and CDS (T1) are deleted. If the global decision is to abort, T1 aborts. The cohorts in the dependency sets of T1 will execute as follows: All cohorts in ADS (T1) will be aborted; All cohorts in CDS (T1) will execute as usual; Sets ADS (T1) and CDS (T1) are deleted.
30
contd
Scenario 2: T2 is going to start processing phase after getting all locks before T1 receives global decision. T2 is allowed to send a WORKSTARTED (discussed later) message to its coordinator, if it is commit dependent only; otherwise it is blocked from sending the WORKSTARTED message (So, the coordinator cannot initiate the commit processing operation) and has to wait, until Alternative 1: either T1 receives its global decisions, or Alternative 2: its own deadline expires, whichever occurs earlier. In case of alternative 1, the system will execute as in scenario 1, whereas in the case of alternative 2, T2 will be killed and will be removed from the dependency set of T1.
Scenario 3: T2 aborts before T1 receives decision

In this situation, T2s updates are undone and T2 will be removed from the dependency set of T1.
31
Basic Idea of Protocol
contd
Sending of WORKSTARTED Message Just Before Start of Processing Phase Allowing Commit Dependent Only Borrower to Send Its WORKSTARTED Message Instead of being Blocked Checking of Completion of Processing & Removal of Dependency Before Sending YES VOTE Message
(A)
Execution Phase is divided in
Locking Phase Processing Phase
32
Cohort Execution
During the locking phase, the transaction locks the data items.
contd
Just before the start of processing phase, the cohort sends a WORKSTARTED message to its coordinator. After the receipt of WORKSTARTED messages from all its cohorts, the coordinator sends VOTE REQ message to all its cohorts at time t calculated as follows: t = Max {ti + Processing_timei} - Tcom where, ti = Arrival time of WORKSTARTED message from cohort i Processing_timei = Processing time needed by the cohort i Tcom= Communication Delay from one site to another
33
(B)
contd
One of the following two decisions is taken based on the types of dependency
T2 sends WORKSTARTED message to its coordinator if it is only commit dependent on other cohorts.
Free from Cascaded Aborts (Abort of T1 (lender) does not cause T2 (borrower) to abort)
T2 is not allowed to send WORKSTARTED message to its coordinator if it is abort dependent on other cohorts. Coordinator cannot initiate commit processing. It has to wait until either T1 receives its global decisions or its own deadline expires, whichever occurs earlier.
34
(C)
If coordinators VOTE REQ message Cohort sends a YES VOTE message, only if No Dependencies It has finished its processing
contd
On receipt of Vote Req. message, one of the following decisions is taken
If it is still dependent on any cohort or has not finished its processing YES VOTE message is deferred. Borrower sends deferred YES VOTE message, after Completion of Processing, and Removal of Dependencies This may be either due to abort or commit of the lender.
35
Algorithm
contd
if (T1 receives global decision before, T2 is going to start processing phase after getting all locks) { ONE: if (T1s global decision is to commit) { T1 enters in the decision phase; All cohorts in ADS (T1) and CDS (T1) will execute as usual; Delete set of ADS (T1) and CDS (T1); } else //T1s global decision is to abort { T1 aborts; The cohorts in CDS (T1) will execute as usual; Transaction in ADS (T1) will be aborted; Delete sets of ADS (T1) and CDS (T1); } } else if (T2 is going to start processing phase after getting all locks before, T1 receives global decision) { Check type of dependencies; 36
if (T2s dependency is commit only) T2 sends WORKSTARTED message; else { T2 is blocked for sending WORKSTARTED message; while (! (T1 receive global decision OR T2 misses deadline)) { if (T2 misses deadline) { Undo computation of T2; Abort T2; Delete T2 from CDS (T1) & ADS (T1); } else GoTo ONE; } }
contd
} else //T2 is aborted by higher transaction before, T1 receives decision { Undo computation of T2; Abort T2; Delete T2 from CDS (T1) & ADS (T1); } 37
SWIFT is compared with protocols PROMPT 2SC SWIFT- Preliminary Version - One (SWIFT-PV-1)
contd
SWIFT- Preliminary Version - Two (SWIFT-PV-2)

SWIFT-PV-1 Basic concept of sending the WORKDONE message only, if cohort is commit dependent on other cohorts.
SWIFT-PV-2 Sending of WORKSTARTED message is considered before the start of processing phase.
SWIFT Combination of concepts of SWIFT-PV-1 and SWIFT-PV-2.
38
Simulation Results
Main Memory Resident Database
100 PROMPT 2SC SWIFT-PV-1
contd
80
60
Miss %
40 20 0 2 4 6 8 10 12 14
Transaction Arrival Rate (no. per second) Fig. 4.1: Miss % with (RC+DC) at Communication Delay=100ms Normal & Heavy Load
39
100 PROMPT 2SC SWIFT-PV-2 80
contd
60
Miss %
40 20 0 2 4 6 8 10 12 14
40
100 PROMPT 2SC SWIFT-PV-1 SWIFT-PV-2 SWIFT
contd
80
60
Miss %
40 20 0 2 4 6 8 10 12 14
Transaction Arrival Rate (no. per second) Fig. 4.3: Miss % with (RC+DC) at Communication Delay=100ms Normal & heavy Load
41
contd
Miss %
40
20
0 10 15 20 25 30 35 40 45 50
42
contd
Miss %
40
20
0 10 15 20 25 30 35 40 45 50
43
contd
60
Miss %
40
20
0 10 15 20 25 30 35 40 45 50
44
Disk Resident Database
25
contd
20
PROMPT 2SC SWIFT-PV-1
15
Miss %
10 5 0 3 4 5 6
Transaction Arrival Rate (no. per second) Fig. 4.7: Miss % with (RC+DC) at Communication Delay=0ms Normal Load
45
contd
80
60
Miss %
40 20 0 6 9 12 15 18
Transactional Arrival rate (no. per second) Fig. 4.8: Miss % with (RC+DC) at Communication Delay=0ms Heavy Load
46
contd
20
15
Miss %
10 5 0 3 4 5 6
47
contd
80
60
Miss %
40 20 0 6 9 12 15 18
48
25
contd
20
PROMPT 2SC SWIFT-PV-1 SWIFT-PV-2 SWIFT
15
Miss %
10 5 0 3 4 5 6
49
contd
80
60
Miss %
40 20 0 6 9 12 15 18
50
contd
80
60
Miss %
40 20 0 2 4 6 8 10 12 14
Transaction Arrival Rate (no. per second) Fig. 4.13: Miss % with (RC+DC) at Communiction Delay=100ms Normal & Heavy Load
51
contd
80
60
Miss %
40 20 0 2 4 6 8 10 12 14
Transaction Arrival Rate (no. per second) Fig. 4.14: Miss % with (RC+DC) at Communiction Delay=100ms Normal & Heavy Load
52
100
contd
80
PROMPT 2SC SWIFT-PV-1 SWIFT-PV-2 SWIFT
60
Miss %
40 20 0 2 4 6 8 10 12 14
Transaction Arrival Rate (no. per second) Fig. 4.15: Miss % with (RC+DC) at Communication Delay=100ms Normal & Heavy load
53
Partial Read Only Optimization
contd
If some of its cohorts have only read operations, no need to be involved in the second phase of protocol because it does not matter whether the transaction is finally committed or aborted to ensure its atomicity at that cohort site. Cohort may send a read-only WORKSTARTED message to its coordinator indicating that it is no longer needed by the cohort to participate further. Minimizes intersite message traffic, execute-commit conflicts and log writes consequently resulting in a better response time. 1% to 5% Improvement in Transaction Miss Percentage Possible Cases of Data Conflicts Update-Update & Update-Read are only possible conflicts with arriving cohorts
54
Dependency Requirement
contd
Abort Dependency (ADS) If transaction T2 reads or updates an uncommitted data item updated by transaction T1, an abort dependency is created from T2 to T1. T2 aborts, if T1 aborts and T2 is not allowed to commit before T1.
Type of Dependencies in Cases of Data Conflicts

Case 1: Update-Update Conflict If both locks are update-locks and HF(T1) MinHF, an abort dependency is defined from T2 to T1. Transaction identity (id) of T2 is added to ADS (T1), and T2 acquires the update-lock; otherwise, T2 is blocked. Case 2: Update-Read Conflict If T2 requests a read-lock while T1 is holding an update-lock and HF(T1) MinHF, an abort dependency is defined from T2 to T1. Transaction identity (id) of T2 is added to ADS (T1), and T2 acquires the read-lock; otherwise, T2 is blocked. 55
Simulation Results
80 SWIFT SWIFT with Partial Read Optimization 60
contd
Miss %
40
20
0 10 15 20 25 30 35 40 45 50
56
contd
Miss %
40
20
0 2 4 6 8 10 12 14
57
contd
Miss %
40
20
0 2 4 6 8 10 12 14
58
contd
Miss %
10
0 3 4 5 6
59
contd
60
Miss %
40 20 0 6 9 12 15 18
60
contd
Effect of Permitting Cohorts to Communicate With Each Other of the Same Transaction (CCST)
Announcement of the abort of a cohort can be directly sent to its sibling as well as its coordinator. No need for coordinator to send the abort message to rest of its cohorts. 1% to 3% Improvement in Transaction Miss Percentage (very limited)
61
80 SWIFT SWIFT with CCST 60
contd
Miss %
40
20
0 10 15 20 25 30 35 40 45 50
62
contd
Miss %
40
20
0 2 4 6 8 10 12 14
63
contd
Miss %
40
20
0 2 4 6 8 10 12 14
64
contd
Miss %
10
0 3 4 5 6
Transaction Arrival Rate (no. per second) Fig. 4.24 Miss % with (RC+DC) at Communication Delay=0ms Normal Load
65
contd
60
Miss %
40 20 0 6 9 12 15 18
66
Main Memory Database with Communication Delay of 100ms
50 Total Transaction Miss % Transaction Miss % During Processing Phase Transaction Miss % Other Than Processing Phase 40
contd
Impact of Early Sending of WORKSTARTED Message
30
Miss %
20 10 0 0 2 4 6 8 10 12 14 16
Transaction Arrival Rate (no. per second) Fig. 4.26: Break-up of Miss % with (RC+DC) at Communication Delay=100
67
Main Memory Database with Communication Delay of 0ms
70 Total Transaction Miss % Transaction Miss % During Processing Phase Transaction Miss % Other Than Processing Phase
contd
60
50
Miss %
40
30
20
10
0 10 15 20 25 30 35 40 45 50 55
Transaction Arrival Rate (no. per second) Fig. 4.27: Break-up of Miss % with (RC+DC) at Communication Delay=0ms
68
Disk Resident Database with Communication Delay of 100ms
80 Total Transaction Miss % Transaction Miss % During Processing Phase Transaction Miss % Other Than Processing Phase 60
contd
Miss %
40
20
0 0 2 4 6 8 10 12 14 16
Transaction Arrival Rate (no. per second) Fig. 4.28: Break-up of Miss % with (RC+DC) at Communication Delay=100
69
Disk Resident Database with Communication Delay of 0ms
100 Total transaction Miss % Transaction Miss % During Processing Phase Transaction Miss % Other Than Processing Phase
contd
80
60
Miss %
40 20 0 4 6 8 10 12 14 16 18 20
Transaction Arrival Rate (no. per second) Fig. 4.29: Break-up of Miss % with (RC+DC) at Communication Delay=0ms
70
Conclusions
SWIFT-A New Real Time Commit Protocol
Performances Comparison with 2SC Communication Delays-Negligible or Large and PROMPT When 5% to 10% Improvement in Transaction Miss Percentage Performances Comparison for Partial Read-Only Optimization 1% to 5% Improvement in Transaction Miss Percentage
Impact of Permitting Communication between Cohorts of Same Transaction (Sibling)

Up to 3% Improvement in Transaction Miss Percentage
71
Scope for Future Research

Performance Evaluation of Proposed Priority Assignment Policy and Commit Protocols on DRTDBS by
Analytical Methods Experimentation in Actual Environment Experimentation in Replicated Environment
Performance Evaluation of Proposed Commit Protocols using

1PC Protocol 3PC Protocol
Performance Evaluation of Proposed Works in

Hard Real Time Environment Soft Real Time Environment
72
Scope for Future Research

Performance Evaluation of SWIFT in
Mobile DTRDBS
contd
An Obvious Extension of Our Work for

Multiprocessor Environment
Fault Tolerance and Reliability Aspects Impact of Communications in between Cohorts of Same Transaction (Siblings) on Overall System Performance. Extension of Our Research Work for Grid Database Systems
73
References
1. Udai Shanker, Manoj Misra and Anil K. Sarje, SWIFT-A New Real Time Commit Protocol, International Journal of Distributed and Parallel Databases, Springer Verlag (online on May 26, 2006). 2. Udai Shanker, Manoj Misra and Anil K. Sarje, Distributed Real Time Database Systems: Background and Literature Review, International Journal of Distributed and Parallel Databases, Springer Verlag (under second review). 3. Udai Shanker, Manoj Misra and Anil K. Sarje, Dependency Sensitive Distributed Commit Protocol, Proceedings of the 8th International Conference on Information Technology (CIT 05), Bhubaneswar, India, Dec. 20-23, 2005, pp. 41-46. 4. Udai Shanker, Manoj Misra and Anil K. Sarje, A Memory Efficient Fast Distributed Real Time Commit Protocol, Proceedings of the 7th International Workshop on Distributed Computing (IWDC 2005), Indian Institute of Technology Kharagpur, India, Dec. 27-30, 2005, pp 500-505.
5. Udai Shanker, Manoj Misra and Anil K. Sarje, Optimizing Distributed RealTime Transaction Processing During Execution Phase, Proceedings of the 3rd International Conference on Computer Application (ICCA2005), University of Computer Studies, Yangon, Myanmar, March 9-10, 2005, pp 1-7.
74
References
contd
6. Udai Shanker, Manoj Misra and Anil K. Sarje, Some Performance Issues in Distributed Real Time Database Systems, Proceedings of the VLDB PhD Workshop, The Convention and Exhibition Center (COEX), Seoul, Korea, Sept. 11, 2006. 7. Udai Shanker, Some Performance Issues in Distributed Real Time Database Systems, PhD Thesis, Department of Electronics & Computer Engineering, Indian Institute of Technology Roorkee, Roorkee-247 667, India, June 2006. 8. Gray Jim and Reuter A., Transaction Processing: Concepts and Technique, Morgan Kaufman, San Mateo, CA, 1993. 9. Gray Jim, Notes on Database Operating Systems, Operating Systems: an Advanced Course, Lecture Notes in Computer Science, Springer Verlag, Vol. 60, pp. 397 - 405, 1978. 10. Lam Kam - Yiu, Concurrency Control in Distributed Real - Time Database Systems, PhD Thesis, City University of Hong Kong, Hong Kong, Oct. 1994. 11. Ulusoy Ozgur, Concurrency Control in Real - time Database Systems, PhD Thesis, Department of Computer Science, University of Illinois, Urbana-Champaign, 1992.
75
Questions and Answers
Thank You
76

SWIFT Presentation

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SWIFT Presentation

Uploaded by

Copyright:

Available Formats

SWIFT

A Real Time Commit Protocol

Dr. Udai Shanker

Dept. of CSE, MMMEC Gorakhpur

Distributed Database System

A Join of Real Time Systems & Distributed Database Systems

Dept. of CSE, MMMEC Gorakhpur

Distributed Real Time Databases

Dept. of CSE, MMMEC Gorakhpur

Dept. of CSE, MMMEC Gorakhpur

Dept. of CSE, MMMEC Gorakhpur

Dept. of CSE, MMMEC Gorakhpur

Obtain state of the

Read data, compute, and report (or send to actuators)

Dept. of CSE, MMMEC Gorakhpur

Data Access Mechanism

Dept. of CSE, MMMEC Gorakhpur

Communication Delays between Different Sites

Dept. of CSE, MMMEC Gorakhpur

ready queue Priority Assignment

Terminate Abort Commit C.C.Manager

wait Queue Database Operation

Blocked Computation Memory

Site 1 Network Manager Site 3

Dept. of CSE, MMMEC Gorakhpur

Dept. of CSE, MMMEC Gorakhpur

Dept. of CSE, MMMEC Gorakhpur

Dept. of CSE, MMMEC Gorakhpur

Rp = max{Tlp Nilocal ,max(Tlp Nij ) + 2Tcom }

R p = (2 Tlock + Tprocess ) N oper_local

Dept. of CSE, MMMEC Gorakhpur

Dept. of CSE, MMMEC Gorakhpur

Write Operation Probability

Dept. of CSE, MMMEC Gorakhpur

Dept. of CSE, MMMEC Gorakhpur

Dept. of CSE, MMMEC Gorakhpur

Commit Protocol Transaction Commit

Dept. of CSE, MMMEC Gorakhpur

All Cohorts Processed

Two-Phase Commit (2PC): Presumed Nothing 2PC protocol (PrN)

Dept. of CSE, MMMEC Gorakhpur

Log Commit Commit

Ack Log END

Log record is forced written

Two Phase Commit (2PC) Protocol

Processing of Access of Data Items in Conflicting Mode by Lock Manager

Dept. of CSE, MMMEC Gorakhpur

Dept. of CSE, MMMEC Gorakhpur

Scenario 3: T2 aborts before T1 receives decision

Dept. of CSE, MMMEC Gorakhpur

Locking Phase Processing Phase

Dept. of CSE, MMMEC Gorakhpur

Dept. of CSE, MMMEC Gorakhpur

Dept. of CSE, MMMEC Gorakhpur

On receipt of Vote Req. message, one of the following decisions is taken

Dept. of CSE, MMMEC Gorakhpur

SWIFT- Preliminary Version - Two (SWIFT-PV-2)

Dept. of CSE, MMMEC Gorakhpur

Dept. of CSE, MMMEC Gorakhpur

Dept. of CSE, MMMEC Gorakhpur

Dept. of CSE, MMMEC Gorakhpur

Dept. of CSE, MMMEC Gorakhpur

Dept. of CSE, MMMEC Gorakhpur

Dept. of CSE, MMMEC Gorakhpur