swift presentation

7/29/2019 SWIFT Presentation

1/76

Dept. of CSE, MMMEC Gorakhpur1

Dr. Udai ShankerDepartment of Computer Science & Engineering

M. M. M. Engineering College, Gorakhpur-273 010

India

SWIFT

A Real Time Commit Protocol


2/76


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


3/76


Real Time Sys tem

Results be produced within a specified deadline period.

Correctness depends on

Logical results of computation, and also

Time at which results will be produced

Distr ibu ted Database Sys tem A Collection of Data Items Distributed over Distant Locations

DRTDBS

A Join of Real Time Systems & Distributed Database Systems

Time Constrained Distributed Database Systems

DRTDBSA Glance


4/76


Real Time Systems vs . DRTDBS

Real Time Systems Task Centric

Deadlines attached to tasks.

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.

DRTDBSA Glance contd


5/76


Satellite

Imagery

News

Services

Need Summary

Report by 4 PM

Troop

Positions

Network

World Wide

Real-Time,DBs

Archival

DBs

The Problem

Scenario

Multimedia

DB



6/76


Transactions

Perform task of setting the value of a real world object.

Are invoked to access databasesby all applications.

Must be scheduled to complete within their time constraint.

Satisfy database constraints.


Notion of Transact ion

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 abortif all changes cannot be successfully made to the

database.


7/76Dept. of CSE, MMMEC Gorakhpur7

d t

v(t)

v0

Hard deadlineHard Real Time Transactions

If deadline missed, catastrophic consequence, either heavy economic or human

safety critical applications

life or environment threatening emergency situations




d t

v(t)

v0

firm deadlineFirm Real TimeTransactions

If deadline missed

Completing the transaction may generate harmful effects onthe system.

It can be, however late result is worthless. Exp-

Transactions attempting to recognize a moving object.

Arbitrage trading.



9/76Dept. of CSE, MMMEC Gorakhpur9d2 t

v(t)

v0

d1

Soft deadline

Soft Real Time Transactions

If deadline missed

Some value even after expiry of its deadlines

Value diminishes with time




Types of Transaction(Operat ions) Write-only Transact ions (Sensor Updates): Obtain state of the

environment and write into the database

Store sensor data in database (e.g., temperature)

Monitoring of environment

Ensure absolute temporal consistency

Update Transact ions (Ap pl icat ion Updates)

Derive new data and store in database

Based on sensor and other derived data

Read-only Transact ions

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




Perfo rmance 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

Performance Issues



I/O & Disk Scheduling

Buffer Management

Communication Delays between Different Sites

Site Failures

Checkpointing and Logging for the Fault Tolerance & Failure Recovery

Predictability & Consistency

Security

CPU Scheduling

Performance Issues contd



Network

ManagerSite 2 Site 3

Site N

Transaction

Manager

Transaction

GeneratorSink

C.C.Manager

Abort

Terminate

MemoryComputation

Commit

Database

Operation

Priority

Assignment wait Queue

ready queue

Blocked

Site 1

DRTDBS Model



Model Assumpt ions

Firm Real Time Transactions

Processing of a transaction requires use ofCPU 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 transactionpre-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 lockingwith higher priorityscheme is used forlocking the data items.

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 cannotpermit another incoming cohort to read or update.

Database is in main memoryor in diskat all sites.

Communication delay is considered either0ms or100ms.

In case of disk resident database, buffer space is sufficiently largeto allow the retention of data updates until commit time.

Cohorts are executed inparallelway.

Operations performed by one cohort are independentof the results of the

operations performed at the other sites.

DRTDBS Model contd



Symbols Meaningmi No. of Cohorts of ith Transaction

No. of Operations in Local Cohort of Ti

No. of Operations in jth Cohort of Ti

Tlock Time Required to Lock/Unlock a Data Item

Tprocess Time to Process a Data Item (Assuming read operation takes

same amount of time as write operation.)

Ncomm No. of Messages Exchanged Between Coordinator and a Cohort

Tcom Communication Delay, i.e., Constant Time Estimated for aMessage Going from One Site to Another

Noper_local Number of Local Operations

Noper_remote Max. No. of Remote Operations Taken Over by All Cohorts

localiN

jiN

DRTDBS Model contd


17/76


Proposed Method fo r Compu tat ion o f Deadl ine

Deadlines-

Expected Execution Times

Deadline (Di) of Transaction (Ti):

Di=Ai+ SF *Ri

Ai - Arrival Time of Transaction (Ti) at A SiteSF - Slack Factor

Ri- Minimum Transaction Response Time Given as

Ri=Rp+Rc

Rp- Time for Execution Phase

Rc- Time for Commitment Phase

DRTDBS Model contd


18/76


Global Transactions

Local Transaction s

gproceslockl TTTp sin2

c comm comR = N T

p local p jp l i l i comR =max{T N ,max(T N )+2T }

imj 1

localj

p lock process oper_localR = (2 T + T ) N

cR = 0

DRTDBS Model contd


19/76


Simu lat ion Detai ls

Event driven simulator was written in C language.

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)

Miss Percentage Values

Normal Load- 0 to 20% Heavy Load- 20% to 100%

100gsinprocesforsystemthetosubmittednstransactioof.no

abortednstransactioofnumber=MP

DRTDBS Model contd


20/76


Two Simu lat ion Models

Main Memory as well as Disk Resident Distributed Real Time DatabaseSystem

Structure of simulation model and method for computation of deadlines

of global & local transactions are same as described previously

Each transactionis 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)

DRTDBS Model contd


21/76


Simu lat ion Parameters

Parameters Meaning Settings

Nsite Number of Site 4

AR Arri val Rate 2-20 Transactions/Second

Tcom

Communication Delay 100 ms or 0 ms (Constant)

SF Slack F actor 1-4 (Unif orm Distribution)

Noper

No. of Operations in a

Transaction

3-20 (Unif orm Distribution)

PageCPU CPU Page Processing Time 5 ms

PageDisk Disk Page Processing Time 20 ms

DBsize Database Size 200 Data I tems/Site

Pwrite

Write Operation Probabil ity 0.60

DRTDBS Model contd


22/76


Commit Protocol

SWIFTStatic Two Phase Lock ing w ith Higher Pr ior i ty Based, Write-

Update Type, Ideal for Fast and Timel iness Commit Protocol

Introduct ion

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 Protoco l - Imp or tant for DRTDBS


23/76


Related Work

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 commitprotocol, Journal of Systems and Software, Elsevier Science Inc, 2003, 1-8.

Commit Protocol contd
http://d/2SC.ppthttp://d/2SC.ppthttp://d/2SC.ppthttp://d/2SC.ppthttp://d/2SC.ppthttp://d/2SC.ppthttp://d/2SC.ppthttp://d/2SC.ppthttp://d/2SC.ppthttp://d/2SC.ppthttp://d/2SC.ppthttp://d/2SC.ppthttp://d/2SC.ppthttp://d/2SC.ppthttp://d/2SC.ppthttp://d/2SC.ppt


24/76


User

Coordinator

Site

Cohort

Site i

Cohort

site j

Cohort

Site n

Commit Protocol

Cohort

site k

Transaction Arrival

All Cohorts Processed

Transaction Commit

Execu

tionPhase

CommitPhase



25/76

Dept. of CSE, MMMEC Gorakhpur

Two -Phase Comm it (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:

Coordinatorsends preparemsg to each cohort.

Cohortforce-writes an abor torpreparelog record and then sends a nooryesmsg to coordinator.

If coordinator gets unanimous yes votes, force-writes a commi t log

record and sends commi tmsg to allcohorts. Else, force-writes abor tlog

rec, and sends abor tmsg.

Cohorts force-write abor t /commit ted logrec based on msg they get,

then sendackmsg to coordinator.

Coordinatorwrites endlog rec after getting allacks.



26/76


Coordinator Cohort

Prepare

Vote YES

Commi t

Ack

Log Prepared

Log Comm it ted

Log Commi t

Log record is forced wr i t ten

VotingPhase

DecisionPhase

Two Phase Comm it (2PC) Protoco l

Log END



27/76


Propo sed Real Time Comm it Protoc ol - SWIFT

Data Ac cess Confl icts Reso lving Strategies

Types of Dependencies (Update Model & Read only)

Comm it 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.

Abo r t 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)

Commit Protocol-SWIFT


28/76


Type of Dependenc ies in Different Cases o f Data

Conf l ic tThree Possible Cases of Conflicts

Case 1: Read-Update Con fl ict .

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 Con fl ic t.

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 Confl ic tIf 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.

Commit Protocol-SWIFT contd


29/76


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);

}elseT2 will be blocked;

}

Processing of A ccess of Data Items in Conf l ic t ing

Mode by Lock Manager



30/76


Mechanics of Interact ion between Lender and

Borrow er Cohor ts

If transaction T2 has borrowed the data item locked by transaction T1,

following three scenarios are possible:

Scenar io 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.



31/76


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 itscoordinator, 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.



32/76


Basic Idea of Protocol

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



33/76


Cohort Execut ion

During the locking phase, the transaction locks the data items.

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_t imei} - Tcom

where,

ti= Arrival time of WORKSTARTED message from cohorti

Processing_t imei= Processing time needed by the cohort i

Tcom= Communication Delay from one site to another



34/76


(B )

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.



35/76


(C)

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

Ifcoordinators VOTE REQ message

Cohort sends a YES VOTE message, only if

No Dependencies

It has finished its processing

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.



36/76


Algor i thmif (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;



37/76


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;

}

}

}

else //T2 is aborted by higher transaction before, T1 receives decision

{ Undo computation of T2;

Abort T2;

Delete T2 from CDS (T1) & ADS (T1);

}



38/76


SWIFT is compared w ith proto cols-

PROMPT

2SC

SWIFT- Preliminary Version - One (SWIFT-PV-1)

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

SWIFT-PV-1 Basic concept of sending the WORKDONE message only, ifcohort 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.



39/76


Fig. 4.1: Miss % with (RC+DC) at Communication Delay=100msNormal & Heavy Load

Transaction Arrival Rate (no. per second)

2 4 6 8 10 12 14

Miss

%

0

20

40

60

80

100

PROMPT

2SC

SWIFT-PV-1

Simulat ion Resu l tsMain Memory Resident Database



40/76




2 4 6 8 10 12 14

Miss%

0

20

40

60

80

100

PROMPT2SC

SWIFT-PV-2

Main Memory Resident Database



41/76


Fig. 4.3: Miss % with (RC+DC) at Communication Delay=100msNormal & heavy Load


2 4 6 8 10 12 14

Miss%

0

20

40

60

80

100

PROMPT

2SC

SWIFT-PV-1

SWIFT-PV-2

SWIFT




42/76




10 15 20 25 30 35 40 45 50

Miss%

0

20

40

60

80

PROMPT

2SC

SWIFT-PV-1




43/76




10 15 20 25 30 35 40 45 50

Miss%

0

20

40

60

80

PROMPT

2SC

SWIFT-PV-2




44/76




10 15 20 25 30 35 40 45 50

Miss%

0

20

40

60

80

PROMPT

2SC

SWIFT-PV-1

SWIFT-PV-2

SWIFT




45/76


Fig. 4.7: Miss % with (RC+DC) at Communication Delay=0msNormal Load


3 4 5 6

Miss

%

0

5

10

15

20

25

PROMPT

2SC

SWIFT-PV-1

Disk Resident Database



46/76


Fig. 4.8: Miss % with (RC+DC) at Communication Delay=0msHeavy Load

Transactional Arrival rate (no. per second)

6 9 12 15 18

Miss%

0

20

40

60

80

100

PROMPT

2SC

SWIFT-PV-1




47/76


Fig. 4.9: Miss % with (RC+DC) at Communication Delay=0msNormal Load


3 4 5 6

Miss%

0

5

10

15

20

25

PROMPT

2SC

SWIFT-PV-2




48/76


Fig. 4.10: Miss % with (RC+DC) at Communication Delay=0ms

Heavy Load


6 9 12 15 18

Miss

%

0

20

40

60

80

100

PROMPT

2SC

SWIFT-PV-2



C i l


49/76



Normal Load


3 4 5 6

Miss

%

0

5

10

15

20

25

PROMPT

2SC

SWIFT-PV-1

SWIFT-PV-2

SWIFT



C i P l


50/76




6 9 12 15 18

Miss%

0

20

40

60

80

100

PROMPT

2SC

SWIFT-PV-1

SWIFT-PV-2

SWIFT



C i P l


51/76


Fig. 4.13: Miss % with (RC+DC) at Communiction Delay=100msNormal & Heavy Load


2 4 6 8 10 12 14

Miss%

0

20

40

60

80

100

PROMPT

2SC

SWIFT-PV-1



C i P l


52/76


Fig. 4.14: Miss % with (RC+DC) at Communiction Delay=100msNormal & Heavy Load


2 4 6 8 10 12 14

Miss%

0

20

40

60

80

100

PROMPT

2SC

SWIFT-PV-2



C i P l


53/76


Fig. 4.15: Miss % with (RC+DC) at Communication Delay=100msNormal & Heavy load


2 4 6 8 10 12 14

Miss

%

0

20

40

60

80

100

PROMPT

2SC

SWIFT-PV-1

SWIFT-PV-2

SWIFT



C i P l


54/76


Part ial Read On ly Optim izat ion

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 thetransaction 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 participatefurther.

Minimizes intersite message traffic, execute-commit conflicts and log writesconsequently resulting in a better response time.

1% to 5% Improvement in Transaction Miss Percentage

Poss ible Cases o f Data Conf l icts

Update-Update & Update-Read are only possible conflicts with arriving cohorts


C i P l


55/76


Dependency Requ irement

Abort Dependenc y (ADS)

If transaction T2 reads or updates an uncommitted data item updated bytransaction 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 o f Data Confl icts

Case 1: Update-Update Confl ic t

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 Confl i ct

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.


C i P l


56/76




10 15 20 25 30 35 40 45 50

Miss

%

0

20

40

60

80

SWIFT

SWIFT with Partial Read Optimization

Simulat ion Resu l tsMain Memory Resident Database


C it P t l


57/76




2 4 6 8 10 12 14

M

iss%

0

20

40

60

80

SWIFT




C it P t l


58/76



Normal & Heavy load


2 4 6 8 10 12 14

Miss%

0

20

40

60

80

SWIFT




C it P t l


59/76



Normal Load


3 4 5 6

Miss%

0

5

10

15

20

SWIFT




C it Pr t l S T


60/76




6 9 12 15 18

M

iss%

0

20

40

60

80

100

SWIFT




Commit Protocol SWIFT


61/76


Announcement of the abort of a cohort can be directly sent to its siblingas 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)

Effect o f Perm it t ing Cohorts to Commun icate With

Each Other of the Same Transaction (CCST)




62/76




10 15 20 25 30 35 40 45 50

Miss%

0

20

40

60

80

SWIFT

SWIFT with CCST

Main Memo ry Resident Database




63/76




2 4 6 8 10 12 14

Miss

%

0

20

40

60

80

SWIFT

SWIFT with CCST





64/76


Fig. 4.23: Miss % with (RC+DC) at Communication Delay=100msNormal & Heavy load


2 4 6 8 10 12 14

Mis

s%

0

20

40

60

80

SWIFT

SWIFT with CCST





65/76


Fig. 4.24 Miss % with (RC+DC) at Communication Delay=0ms

Normal Load


3 4 5 6

M

iss%

0

5

10

15

20

SWIFT

SWIFT with CCST



Commit Protocol SWIFT d


66/76




6 9 12 15 18

M

iss%

0

20

40

60

80

100

SWIFTSWIFT with CCST





67/76

Dept. of CSE, MMMEC Gorakhpur67Fig. 4.26: Break-up of Miss % with (RC+DC) at Communication Delay=100


0 2 4 6 8 10 12 14 16

Miss%

0

10

20

30

40

50Total Transaction Miss %

Transaction Miss % During Processing Phase

Transaction Miss % Other Than Processing Phase

Impact o f Early Send ing of WORKSTARTED MessageMain Memory Database with Commun icat ion Delay of 100ms




68/76

Dept. of CSE, MMMEC Gorakhpur68Fig. 4.27: Break-up of Miss % with (RC+DC) at Communication Delay=0ms


10 15 20 25 30 35 40 45 50 55

Miss%

0

10

20

30

40

50

60

70

Total Transaction Miss %



Main Memo ry Database with Communicat ion Delay of 0ms




69/76

Dept. of CSE, MMMEC Gorakhpur69Fig. 4.28: Break-up of Miss % with (RC+DC) at Communication Delay=100

Transaction Arrival Rate (no. per second)0 2 4 6 8 10 12 14 16

Miss%

0

20

40

60

80

Total Transaction Miss %



Disk Resident Database with Commun icat ion Delay of 100ms


Commit Protocol-SWIFT td


70/76



Fig. 4.29: Break-up of Miss % with (RC+DC) at Communication Delay=0ms


4 6 8 10 12 14 16 18 20

Miss%

0

20

40

60

80

100

Total transaction Miss %



Disk Resident Database with Commun icat ion Delay of 0ms

Conclusions


71/76


ConclusionsSWIFT-A New Real Time Comm it Protoc ol

Performances Comparison with 2SC and PROMPT When

Communication Delays-Negligible or Large 5% to 10% Improvement in Transaction Miss Percentage

Performances Comparisonfor Partial Read-Only Optimization

1% to 5% Improvement in Transaction Miss Percentage

Impact of Permitting Communication between Cohorts of SameTransaction (Sibling)

Up to 3% Improvement in Transaction Miss Percentage

Scope for Future Research


72/76


Scope for Future Research

Performance Evaluationof 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 Evaluationof Proposed Works in

Hard Real Time Environment Soft Real Time Environment

Scope for Future Research contd


73/76


Scope for Future Research contd

Performance EvaluationofSWIFT in

Mobile DTRDBS

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 DatabaseSystems

References


74/76


1. Udai Shanker, Manoj Misra and Anil K. Sarje, SWIFT-A New Real Time Commi t

Protoco l, International Journal of Distributed and Parallel Databases, Springer

Verlag (online on May 26, 2006).

2. Udai Shanker, Manoj Misra and Anil K. Sarje, Distr ib uted Real Time Database

Systems: Back grou nd and L i terature Review, International Journal of Distributed

and Parallel Databases, Springer Verlag (under second review).

3. Udai Shanker, Manoj Misra and Anil K. Sarje,Dependency Sensi t ive Distr ibu ted

Comm it 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 Eff ic ient Fast Distr ibuted

Real Time Commit Protoc ol,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,Optimiz ing Distr ibuted Real-Time Transact ion Proc essing Dur ing Execut ion Phase,Proceedings of the 3rd

International Conference on Computer Application (ICCA2005), University of

Computer Studies, Yangon, Myanmar, March 9-10, 2005, pp 1-7.

References contd


75/76


6. Udai Shanker, Manoj Misra and Anil K. Sarje, Some Performance Issues in

Distr ibuted 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 Distr ibuted 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 andTechnique,

Morgan Kaufman, San Mateo, CA, 1993.

9. Gray Jim, Notes on Database OperatingSystems, Operat ing Systems: an

AdvancedCourse, Lecture Notes in Computer Science, Springer Verlag, Vol. 60,

pp. 397 - 405, 1978.

10. Lam Kam - Yiu, Concurrency Control in Distr ibuted Real - Time Database

Systems, PhD Thesis, City University of Hong Kong, Hong Kong, Oct. 1994.

11. Ulusoy Ozgur, Concurrency Con trol in Real - t ime DatabaseSystems, PhDThesis, Department of Computer Science, University of Illinois, Urbana-Champaign,

1992.

Questions and Answers


76/76

Thank You

swift presentation

Documents