MADAN MOHAN MALAVIYA UNIVERSITY OF TECHNOLOGY, GORAKHPUR

DEPARTMENT OF COMPUTER SCINCE AND ENGINEERING

TOPIC:- Transaction Scheduling in Distributed Real-Time Systems

By:- Mohd Suhail B.Tech,C.S.E , 3rd Year

Distributed And Real Time database system

• In a distributed database system, information is stored across a number of sites interconnected through a reliable communication network. Each site has a system-wide unique identifier, and sites communicate through messages.

IMG:-Real time distributed database system

• A real-time database system (RTDBS) is one whose basic specification and design criteria must include the requirement of meeting the timing constraints of real-time transactions

• A transaction must be completed within a specified time, called deadline.• Common applications of RTDBS can be found in

international financial market systems, air traffic controlling systems, nuclear power plant management

systems and integrated manufacturing systems.

Transactions To Access Data

• Each distributed transaction is a collection of sub-transactions that execute at various sites where the requested data objects reside.

• Each transaction is assigned a globally unique priority based on its real-time constraint.

• A transaction is executed in three phases (Kung, 1981): a read phase, a validation phase and a write phase if the validation is successful.

• Validation phase ensures that the execution of a validating transaction preserves serializability

• Transactions are scheduled to access resources such as CPU and data objects based on their priorities

• The priorities of transactions can be static and dynamic (Ramamritham, 1993).

• dynamic priority assignment achieves better system performance than static one in most cases

• Conflict resolution relies on transaction restart

Goal of scheduling transactions in RTDBS

• To meet the timing constraints• To ensure the data consistency.

concurrency control in database systems can be used to maintain data consistency, there are many protocols for concurrency control, one of them is optimistic concurrency control (occ). It is very popular protocol for RTDBS.

Optimistic concurrency control

• Popular approach to concurrency control for RTDBS

• properties of the OCC protocols are non-blocking, deadlock-free and fruitful restarts

• In OCC protocols, conflict resolution is performed at the end of a transaction execution. Therefore, restarting other conflicting transactions must result in a transaction commitment. We called this fruitful restart

there are three possible types of conflicts write-read conflicts, write-write conflicts , read –write conflicts

adjustment are made to resolve these conflicts may be backward adjustment ,forward adjustment .

• OCC-FV protocol has a serious problem of unnecessary restarts (Lam, 1995; Lee, 1993b) which is caused by an ineffective validation scheme

To Avoid Unnecessary Restarts Dynamic Adjustment of Serialization Order with Thomas’ Write Rule is used

Problem of Unnecessary Restarts

• To reduce the number of unnecessary restarts in OCC protocols,Lee et al (Lee, 1993b) suggested the OCC-TI protocol which utilized the notion of dynamic adjustment of serialization order (DASO) and timestamp intervals (Konana, 1997).

The DOCC-DA Protocol

• In the DOCCDA protocol, serialization order is maintained by assigning timestamps to transactions

• The timestamp of each transaction, called the serialization order timestamp (SOT),

• SOT of a transaction indicates its relative position in the serialization order.

• Each sub-transaction of a transaction Ti will also carry its own SOT(Ti) at its local site to perform its local validation

• In each site, a data object table and a transaction table are maintained.

• The data object table keeps a read timestamp and a write timestamp for each data object in the local database

• They are defined as follows

RTS.(Dx ) : the latest timestamp among the committed transactions that have readthe data object Dx ;WTS.(Dx) : the latest timestamp among the committed transactions that have writtenthe data object Dx :The transaction table at each site maintains the following information for each local activetransaction or sub-transaction Ti :RS.(Ti) : the read set of Ti ;WS.(Ti) : the write set of Ti ;SOT.(Ti ) :0 the serialization order timestamp of Ti ;TR.(Ti ; Dx ) : the value of WTS.(Dx ) of the data object Dx when Ti reads Dx ;

Read Phase

• When a sub-transaction of Ti wants to read or pre-write a data object Dx in its private workspace, it will first obtain the PR-lock or PW-lock respectively. These locks will be granted if there is no VR-lock or VW-lock. In the read phase, there is no need for Ti to detect conflicts. However, the write timestamp of each data object read will be recorded. That is, if Ti wants to read Dx , the value of WTS.( Dx ) will be recorded into TR.(Ti ; Dx ). If Ti wants to write Dx , the new value of Dx will be pre-written into its private workspace.

Validation Phase

• When a sub-transaction of Ti receives a validation packet, it will update its SOT(Ti) if the received SOT(Ti ) is earlier. Afterwards, Ti will upgrade its local PR-locks and PW-locks to the VR-locks and VW-locks respectively one by one. If there is a VR-lock or VW-lock being held by another transaction, Ti will be blocked until the lock is released.

To upgrade the PR-lock to the VR-lock on Dx ; Ti will check the value of TR(Ti ; Dx )to ensure that the version of Dx read by Ti is the one written by a committed transactionwhose serialization order precedes that of Ti , i.e. TR(Ti ; Dx ) is earlier than SOT(Ti ). IfTR(Ti ; Dx ) is later than SOT(Ti ); Ti will send “Abort” message to the parent transaction thatwill globally abort the whole transaction because a committed transaction has invalidatedthe value of Dx that Ti has read. Otherwise, the VR-lock will be granted. If there is a PW lockheld by another transaction, Ti will either create or update the token for the conflictingtransaction and set the FOR flag in the token.

Write Phase

• For each sub-transaction, if a “Commit” message is received, Ti will abort those serious conflicting transactions in the SERIOUS set. For those transactions in BTRAN set, their SOT values are updated to SOT(Ti ) " where " is a sufficiently small value. Then Ti will update the values of RTS.(Dx ) and WTS.(Dx ) to the received SOT.(Ti) value on Dx held by its VR-lock or VW-lock. Finally, the prewritten data objects will be made permanent in the database following Thomas’ write rule. Finally, all its VR-locks and VW-locks will be released. On the other hand, if “Abort” message is received, all its locks are released and all prewritten data objects are disregarded

Conclusions

• The traditional optimistic approach suffers from the problem of unnecessary restarts

• This problem affects the performance of RTDBS as transaction restarts can significantly increase the system workload and intensify resource and data contention

• Transaction restarts in distributed RTDBS make a transaction more difficult to meet its deadline than in a centralized one because of the communication overhead

• new real-time DOCC protocol, called DOCC-DA• alleviates the problem of unnecessary restart

by dynamic adjustment of serialization orders of the concurrent executing conflicting transactions with respect to a validating transaction.

• Under the DOCC-DA protocol, only those transactions with serious conflict with the validating transaction will be restarted

• design of the DOCC-DA protocol is suitable to distributed environments in the sense that it reduces the number message passing between different sites by using a new distributed circular validation scheme

• DOCC-DA protocol gives a greater performance gain when transactions have a large proportion of read operations. by the use of DASO

THANK YOU

QUERIES?