1. DEPARTMENT OF COMPUTER SCINCE AND ENGINEERING
TOPIC:-
Transaction Scheduling in Distributed Real-Time Systems
By:- Mohd Suhail
B.Tech,C.S.E , 3rd Year

2. 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

3. • 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.

4. 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

5. • 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

6. 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.

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

8. 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

9. • 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).

10. 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

11. • 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

12. RTS.(Dx ) : the latest timestamp among the committed
transactions that have read
the data object Dx ;
WTS.(Dx) : the latest timestamp among the committed
transactions that have written
the data object Dx :
The transaction table at each site maintains the following
information for each local active
transaction 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 ;

13. 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.

14. 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.

15. 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 transaction
whose serialization order precedes that of Ti , i.e. TR(Ti ; Dx ) is
earlier than SOT(Ti ). If
TR(Ti ; Dx ) is later than SOT(Ti ); Ti will send “Abort” message to the
parent transaction that
will globally abort the whole transaction because a committed
transaction has invalidated
the value of Dx that Ti has read. Otherwise, the VR-lock will be
granted. If there is a PW lock
held by another transaction, Ti will either create or update the token
for the conflicting
transaction and set the FOR flag in the token.

16. 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

17. 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

18. • 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

19. • 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