• TABLE OF CONTENTS
HIDE
 Title Page
 Table of Contents
 Main






Group Title: Department of Computer and Information Science and Engineering Technical Reports
Title: Alternative Version Concurrency Control (AVCC) for firm real-time database systems
CITATION PDF VIEWER THUMBNAILS PAGE IMAGE ZOOMABLE
Full Citation
STANDARD VIEW MARC VIEW
Permanent Link: http://ufdc.ufl.edu/UF00095354/00001
 Material Information
Title: Alternative Version Concurrency Control (AVCC) for firm real-time database systems
Series Title: Department of Computer and Information Science and Engineering Technical Report ; 95-031
Physical Description: Book
Language: English
Creator: Hong, D.
Chakravarthy, S.
Johnson, T.
Affiliation: University of Florida
University of Florida
University of Florida
Publisher: Department of Computer and Information Science and Engineering, University of Florida
Place of Publication: Gainesville, Fla.
Publication Date: October, 1995
Copyright Date: 1995
 Record Information
Bibliographic ID: UF00095354
Volume ID: VID00001
Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.

Downloads

This item has the following downloads:

1995192 ( PDF )


Table of Contents
    Title Page
        Page i
    Table of Contents
        Page ii
    Main
        Page 1
        Page 2
        Page 3
        Page 4
        Page 5
        Page 6
        Page 7
        Page 8
        Page 9
        Page 10
        Page 11
        Page 12
        Page 13
        Page 14
        Page 15
        Page 16
        Page 17
        Page 18
Full Text

















University of Florida

Computer and Information Science and Engineering


Alternative Version Concurrency

Control (AVCC) for firm real-time

database system

D. Hong
S. Chakravarthy
T. Johnson
EMAIL: sharma@cis.ufl.edu
WWW: http://www.cis.ufl.edu/-sharma

Tech. Report UF-CIS-TR-95-031
(Submitted for publication)

October 1995
(This work is partly supported by the Office of Naval Research and the Navy
Conmnand. Control and Ocean Surveillance Center RDT&E Division, and by the
Rome Laboratory.)


Computer and Information Science and Engineering Department
E301 Computer Science and Engineering Building
:University of Florida, PO Box 116120
Gainesville, Florida 32611-6120


'
a P
'j;
mp~,,



laj3.









Contents


1 Introduction
1.1 Related W ork .. . .................
1.2 Organization . . . . . . . . . . .

2 Motivation for our approach
2.1 Comparison of conflict resolution policies ..

3 Alternative Version Concurrency Control (AVCC)
3.1 Algorithm s . . . . . . . . . . . .
3.1.1 Lock acquire . . .. .. ... ... ...
3.1.2 Com m it . . . . . . . . . . .
3.1.3 D iscard . . . . . . . . . . .
3.2 Properties of AVCC .. . .............

4 Performance Evaluation
4.1 Analysis of Results .. . ..............

5 Conclusions


. . . . . . . .













Alternative Version Concurrency Control (AVCC)

for firm real-time database systems


D. Hong S. Chakravarthy T. Johnson
Database Systems Research and Development Center
Computer and Information Sciences and Engineering Department
University of Florida, Gainesville, FL 32611
Email: {dh2, sharma, ted}@cis.uf edu


Abstract

By definition, firm real-time transactions are discarded when they miss their deadlines, as
there is no value to completing them after they miss their deadlines. Several approaches that
exploit the semantics of firm deadlines to improve the performance of firm real-time database
systems (RTDBS) have been proposed in the literature.
In this paper, we develop a novel policy termed stop/resume deferred restart policy, and a
concurrency control algorithm based on the policy (termed the Alternative Version Concurrency
Control or AVCC). When conflicts (due to priority) occur, AVCC maintains the immediately
restarted version as well as the stop/resume deferred restarted version of a transaction in order
to use one of the two to meet the firm deadline. We show that our policy generates serializable
schedules and is deadlock free. Our simulation results show that AVCC performs substantially
better than the traditionally used 2PL-HP for wide ranges of the system load for firm deadline
transactions.


1 Introduction

Database applications that require time constrained (real-time) response to transactions are be-
coming quite common. Network Services Databases [SBSR93, Red86] and Stock market appli-
cations [AC;.I-"", V.. ] are typical applications of real-time database systems (RTDBS). Real-
time transactions are the basic unit of work for RTDBS and transactions with deadlines have
been categorized into hard, soft, and firm real-time transactions. Transactions with hard dead-
lines have to meet their deadlines; otherwise, the system does not meet the specification. Soft
real-time transactions have time constraints, but there may be still some residual benefit for com-
pleting transactions past their deadline. Conventional transactions with response time require-
ments can be considered soft real-time transactions. In contrast to the above two, firm trans-
actions are those which should not be considered once their deadlines are not met, as there
is no value to completing the transactions after their deadlines. Typically, applications that
have a definite window (e.g., stock market applications [V .. AC;.I "]) within which transac-
tions need to be executed come under this category. There are several research issues [Gra92]
on RTDBS of which the most active is developing transaction scheduling algorithms for soft
and firm real-time transactions. The scheduler of a RTDBS is responsible for assigning priori-
ties [HJC93, HSRT91, LL73, s7'] and resolving access conflicts among transactions based on









priorities [AC:.I19, BMH89, HCL90b, KS91, K.rI'-, K:.'.;: LS93, LS90, Sha-"] Among them
several approaches [AC;:. I- HCL90b, HSRT91, LS93, LLH95] are specifically studied for firm RT-
DBS and several OCC variants have been proposed, and showed the problems of 2PL-HP for firm
deadline transactions. However, 2PL and 2PL-HP yield better performance than OCC or OCC
variants for non real-time and soft deadline transactions. Thus we devise an algorithm which can
reduce wasted restart and wasted wait problem of 2PL-HP for firm deadline while keeping the
advantages of 2PL and 2PL-HP on non real-time and soft deadline transactions. This is necessary
because in many application incoming transactions are usually a mixed load of non real-time, soft
and firm deadline transactions. As a first step, we introduce a deferred restart conflict resolution
policy and compare its advantages and disadvantages. Based on our comparisons of different con-
flict resolution policies we devise a concurrency control algorithm, Alternative Version Concurrency
Control (AVCC), which combines the features of different conflict resolution policies.


1.1 Related Work

Two phase locking with High Priority (2PL-HP) [AC(.I1-] uses blocking and immediate restarts
to maintain the consistency of databases. When a lower priority transaction (LPT) tries to access
the data that is already accessed by a higher priority transaction (HPT) in a conflicting mode, we
block the LPT until the HPT releases the corresponding data. When an HPT tries to access the
data that is already accessed by an LPT in a conflicting mode, we restart the LPT (immediate
restart) and make the HPT access the data.
OCC uses only a validation phase restart at commit time to make databases consistent. With
OCC approach, a policy is needed to resolve the access conflicts during the validation phase. Some
of the policies proposed are commit (always let the transaction being validated commit), priority
abort (abort the validating transaction only if its priority is less than that of each conflicting
transaction), priority wait (wait for higher priority transactions to complete), and opt-sacrifice
(restart the validating transaction if at least one of the transactions in the conflict set has a higher
priority), wait-50 (wait if more than "i11'. of conflicting transactions have higher priorities). The
performances of these policies examined in [HCL90b, HLC91, HSRT91, LS93, LLH95].
Performance comparisons between locking and OCC have been made for conventional and real-
time database systems and are summarized below:

Under most operating circumstances, locking algorithms outperform optimistic algorithms
for non real-time transactions [AD85, ACL87, CS84]. The superiority of locking over OCC
comes from its early stage blocking validation policy which does not waste valuable system
resources.

For soft RTDBS, 2PL-HP adopted priority based High Priority (HP) conflict resolution
method in locking algorithm and showed better performance than 2PL-Wait [ACG .1 9]. 2PL-
HP has been compared to OCC variants and 2PL-HP showed better performance than OCC
for soft deadline systems with finite resources [HCL90a].

For firm RTDBS, OCC always outperforms 2PL-HP in the simulation study of [HCL90a, LS93]
while OCC performs better than 2PL-HP only when data contention is low in the different
study [HSRT91].

A major advantage of the locking algorithm over OCC is its update policy. Locking can be
done with in-place update or deferred update while OCC only can be done with deferred update.









In-place update shows some advantages when most of the transactions successfully commit, because
its commit protocol is simple and effective, while deferred update has advantages when many trans-
actions are aborted, because its rollback mechanism is very simple. Agrawal and DeWitt [AD85]
showed that if the buffer space available to the transaction is large enough to hold all the pages
updated by the transaction until the transaction is validated, the cost of making local copies global
is not significant. Actually, most comparisons in [ACL87, CS84, HCL90b, HSRT91, LS93, LLH95]
do not consider the effects of in-place or deferred update. In this paper we are also going to discuss
concurrency control algorithms without considering the effects of in-place and deferred update.


1.2 Organization

In section 2 we compare conflict resolution policies and explain the motivation of our approach.
Section 3 shows how we can combine 2 different conflict resolution policies, explains the key pro-
cedures and proves the serializability of our approach. Section 4 shows performance evaluation
through simulations on multiple CPUs and disks environment and section 5 concludes our paper.


2 Motivation for our approach

People have showed some possibilities of OCC as a concurrency control mechanism for firm RTDBS
[HCL90b, HLC91, HSRT91, LS93, LLH95]. According to these papers 2PL-HP loses some of its
advantages over OCC because of wasted restart and wasted wait problems even though OCC has
wasted executions by delaying its validation.

wasted restart A wasted restart happens if an HPT aborts an LPT and then the HPT discarded
by missing its deadline. In other words, a transaction which is later discarded can cause
restarts.

wasted wait A wasted wait happens if an LPT waits for the commit of an HPT and later the HPT
is discarded as it misses its deadline. In other words, a transaction which is later discarded
can cause wait of a conflicting LPT.

wasted execution A wasted execution happens when an LPT in commit time validation phase
is restarted due to a conflicting HPT which hasn't finished yet.

If a lock requesting transaction has a higher priority than conflicting transactions, 2PL-HP
aborts the conflicting LPT immediately (immediate restart). Immediate restart is useful when
an HPT has a high possibility of successful commit (i.e., transactions in soft RTDBS) by restart-
ing LPTs as early as possible. In firm RTDBS, however, immediate restart might cause wasted
restarts, which affects the performance adversely. Our observation on the executions of firm dead-
line transactions is that an HPT can proceed without aborting conflicting LPTs if needed when
we use deferred update policy which updates on local copies of data item and makes them global
at commit time. We only need to stop the LPT until the completion (commit or abort) of the
conflicting HPT. If an HPT is discarded by missing its deadline we can execute the stopped LPT
by resuming it. This is what we refer to as the stop/resume deferred restart policy. In order to
differentiate the cause of transaction blocking, we define transaction stopping as follows:









Definition 2.1 (Transaction stopping) Transaction stopping is the '~.1, I ',/ of an LPT and
happens when an HPT tries to access a data item which is accessed by the LPT. This is in contrast
to the term ,,, ,,i which describes the situation when an LPT tries to access a data item accessed
by an HPT and is ri.,', .I for the completion of that HPT.


2.1 Comparison of conflict resolution policies

In order to see the advantages and disadvantages of immediate and deferred restart policies we
illustrate 4 cases that can arise when an HPT and an LPT conflict with each other. These cases
are depicted in Figures 1, 2, 3, and 4. For each case we evaluate 3 different restart methods,
namely, OCC style deferred restart (DR-OCC), immediate restart (IR), and stop/resume deferred
restart (DR-SR).

DR-OCC This policy is exactly the one used by OCC-commit [HCL90a]. The validation and
restart happen at commit time.

IR This policy is exactly the one used by 2PL-HP. The validation and restart are done when data
conflict occurs.

DR-SR This policy uses early stage validation but commit time restart. When an HPT conflicts
with a lock holding LPT we stop the LPT until the completion time of the HPT. If the HPT
completes successfully (commit) then we restart the LPT. Otherwise (i.e., if the HPT aborts)
we resume the LPT.

The following summarizes the alternative outcomes and their relationship to the conflict reso-
lution policies described above:

Case 1: Both LPT and HPT complete successfully as shown in Figure 1. It is clear that immediate
restart is the best for them in order to have the earliest finish time for the LPT.

Case 2: In this case HPT completes successfully and LPT misses its deadline. DR-SR looks better
in terms of wasting the least amount of system resources (as shown in Figure 2), but the LPT's
effective service time of the IR approach is the longest among them. This indicates that IR
has a much better chance of changing Case 2 to Case 1.

Case 3: This case explains wasted restart of 2PL-HP most clearly. In Figure 3, IR is the worst
among them due to wasted restart. Both deferred restart approaches, DR-OCC and DR-SR,
are preferable in this situation. Even though DR-OCC looks the best among them, DR-SR
is equally good because during the LPT's stopped period we can execute other transactions.

Case 4: This case (shown in Figure 4) happens when both HPT and LPT miss their deadlines.
If we consider the waste of system resources, DR-SR is the best as it wastes less resources.
Saving valuable resources reduces transaction arrival blocking under heavily loaded situations
by giving many chances of execution to other transactions. This is likely to happen often in
heavily loaded situations.

By analyzing the 4 alternative outcomes between HPT and LPT transactions, we notice that
combining IR and DR-SR properly could be better than using a single conflict resolution policy.











Deferred Immediate Deferred
Restart (OCC) Restart Restart (Stop-Resume)
L H L H L H
Start 0 O (
data
S9conflict:..

restartO-- stop

restart:
0resta restart commit
commit commit



commit

commit
commit

Figure 1: Case 1: Both transactions finished successfully within their deadlines

Deferred Immediate Deferred
Restart (OCC) Restart Restart (stop-resume)
L H L H L H
Start data 0 O
data
conflict ..

restart .....
2(9-- stop

Start commit commit restart commit


abort abort abort




Figure 2: Case 2: HPT completed successfully, LPT missed


Bases on this strong motivation we propose a new concurrency control algorithm. Our new al-
gorithm is named Alternative Version Concurrency Control (AVCC) because it combines IR and
DR-SR policies together by maintaining IR version and DR-SR version of a transaction at the same
time. In AVCC priorities of transactions are assigned using Earliest Deadline First (EDF) and all
transaction updates are done on local copies and make them global at commit time deferred
update policy.



3 Alternative Version Concurrency Control (AVCC)


A method for gaining the advantages of both DR-SR and IR policies is to use both versions together.
If a lock requesting HPT T, conflicts with a lock holding LPT Th we stop Th and initiate an
additional immediately restarted version Ti (as an alternative of TA). This is the policy adopted by
AVCC and is illustrated in Figure 5. Thus we have a stopped version and a restarted version of the
LPT together at the same time. Even though the stopped version Th takes some space it doesn't




















Immediate Deferred
Restart Restart (stop-resume)


data
conflict


restart


L H


H
)abort








abort


commit


commit


Figure 3: Case 3: HPT missed, LPT completed successfully


Deferred
Restart (OCC)
L H
rt
data
conflict






abort


abort


Immediate
Restart
L H









abort


abort


Deferred
Restart (stop-resume)
L H






stop

resume abort



abort


Figure 4: Case 4: Both LPT and HPT missed their deadlines


Deferred
Restart (OCC)
L H









abort


commit










consume any processing time until it resumes its execution again. Meanwhile, Ti can proceed up
to the data point that caused the stop and work from there after T, commits, instead of starting
from the beginning when T, commits. If T, misses its deadline, Ti is removed from the system and
T/ resumes its work from the stopped position. This approach also can be viewed as a method to
implement partial rollbacks without using the save point mechanism. Ti is a partially rolled back
version of Th when T, commits.
By maintaining the stopped version and initiating the restarted version, AVCC can reduce
wasted restart and wasted execution. In AVCC the execution path of Th and Ti is exactly the
same when T, is still in the system because T, has locks on the shared data and the value of input
data doesn't change within the deadline of T/. DR version Th and IR version Ti has a parent/child
relationship so that Ti can inherit the deadline and priority of Th and can access the data accessed
by Th freely.

HPT
LPT


Th
H :stopped tr
0 : not stopped tr
S: stop relationship
--- : parent/child relationship



Figure 5: Deferred restart and immediate restart versions

During the execution of a transaction, the IR version of a transaction might be stopped again by
another HPT and changed to DR-SR version and initiated a new IR version. Thus in AVCC each
transaction might have multiple DR versions and a single IR version which is the leaf of the family
tree. Only the IR version of a transaction can be allowed to run while the other DR-SR versions
are waiting the resumption. In Figure 6 we illustrate a general view of transactions' execution with
3 transactions, Ti, Tj, and Tk. For each transaction a rectangle represents a local data space for
each version and the dark area in each data space shows how much a version of the transaction
processed the required data. For simplicity we assume that the left one is the data space of right
one's parent and the parent's data space always progresses more than its child's.


3.1 Algorithms

Let's look at a few more cases that could happen with AVCC. In Figure 7, HPT T, conflicts only
with the stopped version Th more than once. This case doesn't cause any problems. If T, commits
we take the restarted version Ti and remove the stopped version Th from the system. When T,
misses its deadline we remove T, and Ti from the system and resume Th from the stopped position.
The case in Figure 8 can happen when transaction T, stopped Th and initiated Ti. After that
another HPT Ts conflicted only with Th. If both of T, and Ts abort, we resume Th from the
stopped position. Otherwise (i.e., if at least one of them commits) we use Ti and remove Th from
the system.
Important procedures of our algorithm are Lock_acquire, Commit and Discard. Our algorithm








Tj Tk


Figure 6: Execution structure of AVCC


LPT


Ti


Figure 7: Conflicts with the same transaction more than once


Figure 8: Conflicts with different transactions









maintains a global shared lock table to implement those key procedures and each version of the
transaction follows 2 phase locking. Each lock table entry contains an object identifier (OID), a
lock mode, number of lock waiter, number of lock granter, a list of lock waiters, and a list of lock
granters. For each transaction we maintain transaction state, stop_cnt, stop_list, av_stoppedcnt,
av_stopped-list, parent, and child field and their meaning and purposes are as follows:


Ti.state
Ti.stoplist


Ti.av_stopped_list
Ti.stop_cnt
Ti.av_stopped_cnt
Ti.parent

Ti.child


State of transaction Ti (READY, STOPPED, BLOCKED)
The list of object identifier and stopped transactions' TID
when the transaction Ti stopped a transaction. This list is
used to implement deferred restarts when a transaction commits.
The list of object identifier and TID of the transaction that stopped Ti.
The number of lower priority transactions stopped by the transaction Ti.
The number of higher priority transactions that stopped Ti.
A pointer to Ti's parent.
This field is used when we check the transaction stop relationship.
A pointer to Ti's child.


3.1.1 Lock acquire


When a transaction requests a lock on a data object, the lock compatibility and parent/child
relationship should be checked. If a lock requesting higher priority transaction T, conflicts with a
lower priority transaction Th we stop Th and make T, get the lock and initiate Ti which is restarted
version of Th. If a lock holding Th is the ancestor of lock requesting T,, T, gets the lock freely.

Procedure Lock_acquire(Tr, old, lockmode)
BEGIN
IF (oid is locked with a conflicting granted lock mode)
THEN
IF (Th is Tr's ancestor)
Lock_granted(Tr, old, lockmode);
ELSE
IF (Pr(Tr) is greater than or equal to Pr(Th))
THEN


IF (Th.state is STOPPED)
Add oid, and TID of Th to Tr's
Add oid, and TID of Tr to Th's
Change lock owner oid from Th


ELSE







ELSE


stoplist;
av-stoppedlist;
to Tr;


stop Th and
generate Ti which is restart version of Th;
Add STOPPED flag to Th;
Add oid, and TID of Th to Tr's stoplist;
Add oid, and TID of Tr to Th's av_stoppe
Change lock owner oid from Th to Tr;


List;









Block(Tr);
ELSE /* lock compatible */
Lock_granted(Tr,oid,lockmode);
END


3.1.2 Commit

We make local copies global and remove stopped versions here. When the transaction Ti commits
(as in Figure 9) Ti uses its stoplist to remove transactions that are stopped by Ti and ancestors of
those stopped transactions. Thus when Ti commits, TA which is in stoplist of Ti and Ta which is
parent of TA are removed. Figure 10 shows a special case for chain stop. Transaction T2 stopped T3
for object 01 and Ti stopped T2 again for the same object 01. In this case, commit of Ti initiates
the removal of T2 and T3.


Commit


Ti


Figure 9: Transaction commit in AVCC


Procedure Commit(T1)
BEGIN
Make local copies global;
IF (Tl.stop_cnt is greater than zero)
FOREACH Ti in Tl.stoplist
BEGIN
Check chain stop;
Remove all stopped versions that are in Tl.stoplist
and their ancestors;
Remove all locks held by T1;
END
END









Commit


Figure 10: Transaction chain stop in AVCC


3.1.3 Discard

This function is called

1. when a transaction is removed by missing its deadline, (for example, transaction B in the
Figure 11)

2. when a transaction commits and try to remove all transaction that are in its stopJist,

3. when a restarted version of a transaction is removed due to the removal of the transaction
that caused the restart version. (for example, Ai in case 1 of Figure 11)

Figure 11 shows the changes of transactions' relationship in the system when a transaction is
discarded by missing its deadline.
Discarding a transaction requires a proper lock transfer to its stopped version. When the
transaction T, is discarded lock owner of an object 01 which is locked by T, is changed to Ti if it is
used to stop transaction Ti. At the same time transactions blocked for lock release of 01 are waken
up and try a lock on 01 and compare the priority with Ti. By doing this transaction Tb which has
an intermediate priority (i.e., Pr(Ta) > Pr(Tb) > Pr(Ti)) will not be blocked by Ti and won't
form circular waits.

Procedure Discard(Ta)
BEGIN
IF (Ta.stop_cnt is greater than zero)
FOREACH Ti in Ta.stoplist
Change lock owner of OID which caused stop of Ti from Ta to Ti
and wake up transactions blocked for OID;
Delete Ta from the avstoppedJist of Ti;
IF (Ti.av_stopped_cnt is zero)
/* Tc is child of Ti */










Discard vlscara
Case 1 Case 3

Add Ad
dAd

C
Ai Ai





C









Figure 11: Changes of transaction relationship after discard

IF (Tc.state is STOPPED)
Remove Tc and parent/child field

of Tc's parent and child;






ELSE
Figure 11: Changes of transaction relationship after discard


IF (Tc.state is STOPPED)
Remove Tc and .r1ii'-l parent/child field
of Tc's parent and child;
ELSE
Remove Tc and .,.11i-1i child field of Tc's parent;
Resume Ti;
Remove all locks held by Ta;
Remove all data structure for Ta from the system;
END



3.2 Properties of AVCC

Theorem 3.1 AVCC is serializable.


Proof: To prove a history H serializable, we have to show that SG(H) is acyclic. Let T1 and T2
(here, subscript is transaction identifier and superscript represents version number) be two
committed versions of transactions in a history H produced by AVCC. If there is an edge
T -1 T2m in SG(H), there exist conflicting operations q and p such that q1[x] < I' ['].

If Pr(T') > Pr(T2), then qj[x] < ... < Cj < pj [x] ... < Cm.

case 1 If Tf has never been stopped during its execution, Tj( releases its locks at commit
time. Thus T2m cannot access the data x until the commit of transaction T1'.
case 2 If Tli has been stopped by Tih due to data x during its execution, Ti must have
a higher priority than T1. During that period T2m cannot access the data x because
TI has the lock on x. After TI releases its lock on x by finishing its execution









(removed), Tli gets the lock again by lock transfer from T1. Thus T2m cannot access
the data x until the commit of transaction Ti".
case 3 If T1' has been stopped by T/ due to data y which is different from data x
during its execution, T1 must have a higher priority than T1. During that period
T~2 cannot access the data x because T1' or Tl+2 which is a descendant of T1' has
the lock on x. After Tl'+i releases its lock on x by finishing its execution (i.e., Tl is
discarded), T gets the lock again by lock transfer from its descendant Tl+i. Thus
T2m cannot access the data x until the commit of transaction T1".
If Pr(Tt") < Pr(T2m), then q[x] < ... < < I' [']" C< C.2
Let's assume p and q the first conflicting operation between T1' and T2m. If 1' [x]
appears before C7 Tl1 cannot commit because T2m has the higher priority than Tj"
and T2m is the committed transaction.

Suppose there is a cycle T1' T2ml ... -l i T' in SG(H).

Case 1 When Pr(Tl ) < Pr(Tl ),

TU -... Tf implies C0 < C and T Tl implies C < C0

Contradiction. Thus this one cannot happen.
Case2 When Pr(Tl ) > Pr(Tl)

TU T implies C0 < C and T Tl implies C^ < C0

Contradiction. Thus this one cannot happen either.

Therefore no cycle can exist in SG(H) and thus our approach only produces serializable
histories. o

Theorem 3.2 AVCC is deadlock free.

Proof: We use EDF dynamic priority assignment with static evaluation policy for AVCC. Thus
priorities of transactions doesn't change after their arrival. A transaction with lower priority
waits for the completion of higher priority transaction but higher priority never waits for the
completion of lower priority transactions when data conflicts happen. Therefore no wait cycle
can exist and thus our approach doesn't have deadlock. o


4 Performance Evaluation

In order to compare the performance of AVCC, simulations of a real-time transaction scheduler were
implemented (using SIMPACK simulation package [Fis92]). In our simulations we are assuming
multiple CPUs, which has a common queue for the CPUs and the service discipline is priority
Preemptive-Resume and multiple disks environment with each of the disks with its own queue and
the service discipline is priority Head-Of-Line (Non-preemptive).
The parameters used in the simulations are shown in Table 1 and transactions enter the system
according to a Poisson process with arrival rate A (i.e., exponentially distributed inter-arrival times



































Figure 12: Open Network Model for the simulation











Parameter Value
db_size 1000
max_size 24
min_size 8
i/o_time 20 ms
cpu_time 10 ms
disk_prob 0.5
min_slack 100 ( ,)
max_slack 650 ( .)
no_of_cpu 8
no_of_disk 16


Table 1: Parameters for simulations









with mean value 1/A), and they are ready to execute when they enter the system (i.e., release time
equals arrival time). The number of objects updated by a transaction is chosen uniformly from the
range of min_size and max_size and the actual database items are chosen uniformly from the range
of db_size.
After accessing an object a transaction spends cpu_time in order to do some work with or on
that object and then it accesses the next object. The assignment of a deadline is controlled by the
resource time of a transaction and two parameters min_slack and max_slack which set, respectively,
a lower and upper bound of percentage of slack time relative to the resource time. A deadline
is calculated by adding resource time and slack time. Slack time is calculated by multiplying
slack percent and resource time. Slack percent is chosen uniformly from the range of min_slack to
max_slack.

slack percent
Deadline = arrival time + resource time x (1 + 100 )
100

Disk accesses are controlled by disk_prob when a transaction reads an object. The use of
disk_prob to some extent models data maintained in the buffer. At commit time, objects that have
been updated are flushed. The restarted transaction will access the same data objects and the
number of CPU and disk is controlled by no_of_cpu and no_of_disk, respectively.
In our performance evaluation, we measure the transaction miss percent (defined below) com-
monly used in the literature for firm RTDBS:

.s P t Total number of transactions that missed the deadline
Miss Percent = x 100
Total number of transactions that entered the system

We ran 10,000 transactions for each simulations and 'i ,'. confidence intervals have been obtained
whose halfwidths are less than 2..' During our simulations first 1,000 transactions were not
counted in simulation results in order to avoid the warm up problem (initial transient problem).


4.1 Analysis of Results

During our comparisons we did not consider implementation overhead. We believe that the im-
plementation overhead related to AVCC is not significant to affect the results of our simulation
because maintaining a few lists and doing those in-memory operations on the lists do not require
substantial processing time. In terms of space, AVCC requires more data space than EDF-HP
by maintaining IR and DR-SR versions of a transaction. The space problem might be trivial if
we consider memory prices that are dropping severely and the primary goal of real-time systems,
timely responses, which usually requires some redundant resources.
In our experimentation we changed transaction arrival rate from 10 to 110 trs/second and
priorities of transactions are assigned by using EDF policy for EDF-HP and AVCC. As we can see
in Figure 13 AVCC shows better performance than EDF-HP for the wide ranges of system load.
AVCC is much better than EDF-HP except for heavily loaded situation in which AVCC did not
have much chances to reduce wasted restart because most of transactions in this load missed their
deadlines as explained in Figure 4. In normal load most of cases are Case 1, 2, and 3 of Figure 1,
2, and 3 in which maintaining both of IR and DR-SR together reduces wasted restarts and wasted
executions together while initiating IR version in heavy load increases the competition of active
resources by wasting system resources as in case 4 of Figure 4.









100


c 60



S40



20



0


20 40 60 80 100
Arrival Rate(trs/sec)


Figure 13: Comparisons of EDF-HP and AVCC

5 Conclusions

Transaction scheduling is responsible for assigning priorities to transactions and resolving data
conflict among transactions. EDF-HP uses blocking and IR restart policy while OCC uses commit
time restart policy to resolve data conflicts. In this paper we have proposed a new method, AVCC,
to combine IR and DR-SR conflict resolution policies to exploit the advantages both of IR and
DR-SR conflict resolution policies. Our new method, AVCC, maintains IR version and DR-SR
version of a transaction together to reduce wasted restart and wasted execution by requiring more
spaces than EDF-HP.
Our simulations indicate that:

1. AVCC misses less transactions than EDF-HP for all ranges of system load.

2. AVCC shows good performance in normal load of RTDBS. In normal load of systems around
21'. of incoming transactions miss their deadlines and that is the way most of real-time
systems run for most of the time. If we consider the normal load, we can conclude that
AVCC is very useful.

In this paper we did not compare the performance of AVCC to OCC variants directly be-
cause the performance of 2PL-HP and OCC changes with data contention for firm deadline trans-
actions [HSRT91] and 2PL-HP is better than OCC for non real-time or soft deadline transac-
tions [ACL87, HCL90a]. In real applications such as Network Service Databases [SBSR93, Red86]
or Stock market applications [AC ;.1I" V. .. 7I] incoming transactions are usually mixed load of non
real-time, soft and firm transactions. 2PL-HP and AVCC can easily deal with those situations by
assigning priorities so that all priorities of soft deadline transactions are lower than those of firm









deadline transactions and priorities of non real-time transactions are lower than those of soft dead-
line transactions. By maintaining IR version only for non real-time or soft deadline transactions
and IR and DR-SR versions together for firm deadline transactions AVCC can deal with mixed
load situations without any difficulties. But OCC variants cannot easily handle those situations
with simple adjustments. They might need a more complex validation mechanism to handle non
real-time, soft and firm deadline transactions together with OCC which cannot handle non real-
time, and soft deadline transactions efficiently because it uses commit time validation mechanism.
Currently we are looking at these practical situations.


References

[ACL87] Rakesh Agrawal, Michael J. Carey, and Miron Livny. Concurrency control performance
modeling: Alternatives and implications. AC if Transactions on Database Systems,
12(4' 1,.1i' ,.. 1, 11, .-.

[AD85] Rakesh Agrawal and D. DeWitt. Integrated concurrency control and recovery mech-
anism: Design and performance evaluation. AC if Transactions on Database Systems,
10(4):529-564, 1', -.

[ACG.I "] Robert Abbott and Hector Garcia-Molina. Scheduling real-time transactions: a perfor-
mance evaluation. In Proceedings of the 14th VLDB, pages 1-12. AC'.I, 1''-

[ACG.I1S9] Robert Abbott and Hector Garcia-Molina. Scheduling real-time transactions with disk
resident data. In Proceedings of the 15th VLDB, pages .' .-396. AC':.I 1','-

[BMH89] A. Buchmann, D.R. McCarthy, and M. Hsu. Time-critical database scheduling: A
framework for integrating real-time scheduling and concurrency control. In Proceedings
of the Fifth Conference on Data E,-', i pages 470-480, Feb 1','-

[CS84] Michael J. Carey and Michael R. Stonebraker. The performance of concurrency control
algorithms for database management systems. In Proceedings of the 10th VLDB, pages
107-118. AC':.I, 1', 1.

[Fis92] Paul A. Fishwick. SIMPACK:C-based Simulation Tool Package Version 2. University of
Florida, 1992.

[Gra92] Marc H. Graham. Issues in real-time data management. Journal of Real-Time Systems,
4:185-202, 1992.

[HCL90a] Jayant R. Haritsa, Michael J. Carey, and Miron Livny. Dynamic real-time optimistic
concurrency control. In Proceedings of Real-Time System Symposium, pages 94-103.
IEEE, 1990.

[HCL90b] Jayant R. Haritsa, Michael J. Carey, and Miron Livny. On being optimistic about real-
time constraints. In Symposium of Principles of Database systems, pages 331-343. AC'. 1
1990.

[HJC93] D. Hong, T. Johnson, and S. Chakravarthy. Real-time transaction scheduling: A Cost-
Conscious Approach. In Proceedings of the 1'r' ,* AC 1i SIC( IOD I,, Conference on
J,. i. 1.,,,1 ,. / of Data, pages 197-206. AC':.I 1993.









[HLC91] Jayant R. Haritsa, Miron Livny, and Michael J. Carey. Earliest deadline scheduling
for real-time database systems. In Proceedings of Real-Time System Symposium, pages
232-242. IEEE, 1991.

[HSRT91] Jiandong Huang, John A. Stankovic, Krithi Ramamritham, and Don Towsley. Exper-
imental evaluation of real-time optimistic concurrency control schemes. In Proceedings
of the 17th VLDB, pages 35-46. AC' .I 1991.

-. r1'21] Tei-Wei Kuo and Aloysius K. Mok. Application semantics and concurrency control of
real-time data-intensive applications. In Proceedings of Real-Time Systems Symposium,
pages 35-45. IEEE, 1992.

K.I',.:] Tei-Wei Kuo and Aloysius K. Mok. SSP: a semantics-based protocol for real-time data
access. In Proceedings of Real-Time Systems Symposium, pages 76-86. IEEE, 1993.

[KS91] Woosaeng Kim and Jaideep Srivastava. Enhancing real-time DBMS performance with
multiversion data and priority based disk scheduling. In Proceedings of Real-Time Sys-
tems Symposium, pages 222-231. IEEE, 1991.

[LL73] C.L. Liu and J.W. Layland. Scheduling algorithms for multiprogramming in a hard
real-time environment. Journal of AC 11II II2, 1.1, 1973.

[LLH95] Kwokwa Lam, Kamyiu Lam, and Sheunglun Hung. An efficient real-time optimistic
concurrency control protocol. In Proceedings of AC I1 Workshop on Active and Real-
Time database systems, pages 100-110. AC(.I 1995.

[LS90] Yi Lin and Sang H. Son. Concurrency control in real-time databases by dynamic ad-
justment of serialization order. In Proceedings of Real-Time Systems Symposium, pages
104-112. IEEE, 1990.

[LS93] Juhnyoung Lee and Sang H. Son. Using dynamic adjustment of serialization order for
real-time database systems. In Proceedings of Real-Time Systems Symposium, pages
66-75. IEEE, 1993.

[Red86] N. Redding. Network Services Databases. In IEEE Global Telecommunications Confer-
ence, volume Vol. 3, pages 1336-1340. IEEE, 1''i.

[SBSR93] R.M. Sivasankaran, B.Purimetla, J.A. Stankovic, and K. Ramamritham. Network ser-
vices database a Distributed Active Real-Time Database (DARTDB) application. In
Proceedings of IEEE Workshop on Real-Time Applications, pages 184-187. IEEE, 1993.

['-il.'"] Lui Sha. Concurrency control for distributed real-time databases. SI(C I[OD RECORD,
17(1):82-98, 1',--

['Z"-] John A. Stankovic and Wei Zhao. On real-time transactions. SI(C I[OD RECORD,
17(1):4-18, i',--

[\ ." ;] John Voelcker. How computers helped stampede the stock market. IEEE Spectrum,
24:30-33, 1', .




University of Florida Home Page
© 2004 - 2010 University of Florida George A. Smathers Libraries.
All rights reserved.

Acceptable Use, Copyright, and Disclaimer Statement
Last updated October 10, 2010 - - mvs