Incorporating real-time scheduling methods into database management systems

Brief

Communication

Incorporating

real-time

_scheduling

methods

into

database

management systems

Özgür

Ulusoy

Bilkent

_University,

Ankara,

Turkey

Received 14 _January 1995

Revised 15

_February

1995

Abstract.

Many

database

_applications

_today

are characterised

by

the

requirement

of

_timely

access to data. This

_requirement

leads to an

_increasing

trend towards

adapting

real-time

scheduling techniques

to the _management of data access

requests. In this _paper, we summarise and stimulate

devel-opments of

_{time-cognisant}

_{scheduling techniques}

for data-base _{management systems.} In

_particular,

we review

_briefly

the methods used in

_{mapping timing}

constraints of

trans-actions into

_priorities,

and the

_{priority-based protocols}

used for _{concurrency control. We also suggest} useful directions

for future research.

1.

Introduction

An

_increasing

number of database

_{applications today}

are characterised

_by

the

_requirement

to access and

manipulate

data in a

_timely

manner.

_Among

those

application

areas are information retrieval

_systems,

computer-integrated manufacturing,

airline

reserva-tion

_systems,

stock

market,

_banking,

and command

and control

_systems.

As

_opposed

to conventional

data-base

_{management systems}

_(DBMSs),

the DBMS of such

applications

not

_only

has to maintain the

_consistency

of the

_underlying

database,

but also

_satisfy

_timing

constraints associated with transactions. Consider a

transaction that is executed in a stock market to

_update

the database with new information. The transaction needs to

_satisfy

certain

_timing

constraints to ensure that

the database contains an accurate

_{representation}

of the

current market

[1].

As another

_example,

a transaction

may be executed to learn the

price

of a

particular

stock.

The result of the transaction should return as

_quickly

as

possible

since the

_prices

can

change

_very

quickly.

The

_major

_{challenge posed}

to the researchers is to

adapt

real-time

_scheduling

methods to DBMSs.

However, the

_{scheduling algorithms}

used in real-time

systems

assume in

general

a

_priori

_knowledge

about

the characteristics of transactions, such as arrival _time,

data/resource access

_pattern,

worst case execution

time, etc.

Thus,

it is

_predictable

whether the time constraints of a transaction can be satisfied. In a

data-base

_system,

on the other

hand,

there exist a number

of sources of

_{unpredictability}

[7].

(1)

Transactions

_might

have

_conflicting

accesses on

data and hardware resources. Access conflicts

usually

lead to

_blocking

of transactions.

(2)

The execution

_path

of a transaction is

dependent

on the current values of data.

(3)

Delay

due to

_dynamic

_paging

and I/O

_might

be

experienced.

(4)

To maintain database

_consistency,

it

_might

be necessary to abort and later restart a

transac-tion.

All these factors make it

_{virtually impossible}

to

predict

computation

times of database transactions.

As a

_result,

real-time

_scheduling

methods cannot be

directly applied

to database

_systems.

However, it is

quite

possible

to use some ideas from real-time

sched-uling

in

_extending

traditional database

_management

techniques

to observe

_timing

constraints of

trans-actions.

Correspondence

to: Dr O.

_Ulusoy,

_Department

of

_Computer

Engineering

and Information Science, Bilkent

_University,

Bilkent, Ankara _06533,

_Turkey.

Fax: +90 312 266 4126.

Our

_goal

in this _{paper is} to summarise and stimu-late

_developments

of

_{time-cognisant}

transaction

sched-uling techniques

in DBMSs. We outline

_approaches

to

various

_aspects

of

_processing

transactions that are

associated with

_timing

constraints. We also

_suggest

useful directions for future _progress.

_Throughout

the paper, we

explain

the

_concepts

at an _{intuitive, rather}

than at a detailed

_technical,

level. The next section

provides

an examination of methods used in

_mapping

timing

constraints of transactions into

_priorities.

Section 3 discusses

_{priority-based}

_concurrency control

techniques

that control the interaction _among

concur-rently

executing

transactions to

_satisfy

both the

consis-tency

requirement

of the database and the

_timing

constraints of transactions. Section 4

_provides

some

concluding

remarks. 2.

_{Priority assignment}

The

_timing

constraint of a transaction

typically

takes

the form of a deadline. The deadline of a transaction indicates that it is

_required

to

_complete

the transaction before a certain time in the future. A

_typical

categori-sation of transactions concerns the strictness of the

deadlines

_assigned.

o Hard deadline transactions are associated with

strict deadlines and the correctness of transaction

operations

depends

on the time at which the results are

produced

[12].

The

_system

must

provide

schedules that

_guarantee

deadlines.

o

_Soft

deadline transactions are scheduled based on

their

deadlines,

and satisfaction of deadlines is still an

_important

performance goal

in

scheduling

transactions;

however,

in this case, there is no

guarantee

that all deadlines will be met. A soft

deadline transaction is executed until

_completion,

regardless

of whether its deadline has

_expired

or

not.

9 Firm deadline transactions also do not _{carry strict}

deadlines,

i.e.

_missing

a deadline may not result

in a

_catastrophe,

but,

unlike soft deadline

transac-tions,

they

are aborted

by

the

_system

once their

deadlines

_{expire. Typically,}

no value will be

imparted

to the

_system

if a firm deadline

transac-tion misses its deadline.

Processing

hard deadline transactions in a database

system

is

_generally

considered to be infeasible

be-cause, as we discussed

earlier,

it is difficult to

_predict

computation

times and thus to

_provide

schedules that

guarantee

deadlines. Real-world

_examples

of

applica-tions

_supporting

soft or firm deadline transactions are

provided

in

[1].

Banking

systems

and airline-reserva-tion

_systems

_usually

process soft deadline

transac-tions. When a customer submits a _transaction, if the

system

cannot

_generate

a _response to the transaction

within its

deadline,

the customer

_prefers

_getting

the response late to not

getting

it at all. Stock market

trading

is an

_example

of

_applications

_supporting

firm

deadline transactions.

If,

for instance, a transaction is

submitted to learn the current

_price

of a

particular

stock,

the

_system

should either return the result in a

specified

time

_period

or not

_perform

the

_operation

at

all,

because conditions in the stock market can

change

very

quickly.

As stated

before,

one of the

_primary

scheduling

goals

in

_processing

time-constrained transactions is to meet transaction deadlines. The scheduler thus

_assigns

a

_priority

to each transaction based on its deadline. Two of the most

_popular

_{priority assignment}

schemes based on transaction deadlines are:

(1)

earliest deadline

_first

_(EDF):

a transaction with an

earlier deadline has

_higher

_priority

than a

trans-action with a later

_deadline;

(2)

least slack

_first

(LSF):

the slack time of a

transac-tion is defined as the maximum

_length

of time the

transaction can be

delayed

and still

satisfy

its

deadline. The LSF

_{policy assigns}

the

_highest

priority

to the transaction with the least slack time. When a transaction T arrives at the

_system,

its slack time ST

T can be evaluated

using

the

following

formula:

where

_{DT, ATT,}

and

_ET

_denote

the

deadline,

the arrival _time, and the estimated execution time of

transaction T,

_{respectively.}

The LSF

_policy

assumes that each transaction

_provides

its

execu-tion time estimate. The

_dynamic

version of the LSF deadline

_assignment

scheme

_requires

the evaluation of transaction

_priorities

at each

deci-sion

_point

[6].

Let

_PTT

_{and STT(t)}

denote the

processing

time

_spent

so far

by

T and the slack

time of T at time t,

_{respectively.}

The slack time of

T at decision

_point

t can be determined

by

the

following

formula:

The EDF

_policy

is

_{usually preferred}

to LSF because

the estimate of execution times is often unavailable for database transactions.

Some

_applications

_may

_assign

different values to

transactions, where the val ue of a transaction reflects

transaction is

_completed

before its deadline

[4].

The

scheduling goal

for such

_applications

is to maximise the value realised

_by

the

_completed

transactions. Some

algorithms

were

_provided

to establish a

_priority

ordering

among transactions that are

distinguished by

both values and deadlines

[2, 4].

A _{range of trade-offs}

between value and deadline has been covered in those

algorithms.

One common

_algorithm

_gives

_equal

_weight

to deadline and value in

_determining

the

_priority

of transactions. The

_priority

_PT

_of

transaction T is

speci-fied

_by

_{PT = V/D~.,}

where

_V

_denotes

the value of

trans-action T. A variation of this

_algorithm

uses the relative

deadline instead of the absolute deadline in

_assigning

priorities.

The relative deadline is defined as the

difference of the transaction deadline and the

trans-action arrival time, i.e.

_{PT =}

_{~/D~ - ~7~.}

3.

_{Time-cognisant}

_concurrency

control

If the transactions

_processed

in a database

_system

are

associated with

deadlines,

implementation

of

concur-rency control

protocols

in that

system

is difficult due

to the

_conflicting

_requirements

of

_meeting

deadlines and

_maintaining

data

_{consistency. Concurrency}

control

_{protocols proposed}

so far to _{preserve data}

consistency

in conventional database

_systems

are all

based on transaction

_blocking

and transaction restart, which makes it difficult to

_satisfy

deadlines.

Thus,

a

need has arisen for

_developing

_concurrency control

protocols

that take the

_timing

constraints into account while

_scheduling

transactions. Some

_scheduling

tech-niques

have been borrowed from real-time

_systems

to

be used in

_developing

such

_protocols.

There is a

_growing

literature about

_development/

evaluation of

_{time-cognisant}

_concurrency control

protocols

for database

_systems

_(e.g.

[1,

3, 5, 9,

13]).

In this _section, we

_give

an overview of the

_protocols

available in the literature.

In a lock-based concurrency control

_protocol,

a

situ-ation that needs to be

_carefully

handled is

_priority

inversion.

_Priority

inversion can be defined as

uncon-trolled

_blocking

of

_high

_priority

transactions

_by

lower

priority

transactions

[8].

Two main

_approaches

have

been

_pursued

to solve the

_priority

inversion

_problem:

priority

inheritance

_(PI)

and

_priority

abort

(PA).

They

are both

_{time-cognisant}

extensions of the conventional

two-phase locking

(2PL)

protocol.

Variations of these

approaches

have been the basis for the other lock-based concurrency control

protocols.

PI,

_{proposed by}

Sha et al.

[9],

ensures that when a

transaction blocks

_higher

_priority

_{transactions,} it is

executed at the

_highest

_priority

of the blocked

trans-actions ; in other

words,

it inherits the

_highest

_priority.

Due to the inherited

_priority,

the transaction can be

executed

faster,

_resulting

in reduced

_blocking

times for

high

priority

transactions.

PA

_prevents

_priority

inversion

_{by aborting}

low

priority

transactions whenever _necessary

[1].

In

resolv-ing

a data lock

conflict,

if the transaction

_requesting

the lock has

_higher

_priority

than the transaction that holds the

lock,

the latter transaction is aborted and the lock is

_granted

to the former one.

_Otherwise,

the

lock-requesting

transaction is blocked

_by

the

_higher

_priority

lock-holding

transaction. A

_high

_priority

transaction

never waits for a lower

_priority

transaction. This

condition

_prevents

deadlocks if we assume that the

real-time

_priority

of a transaction does not

_change

during

its lifetime and that no two transactions have

the same

_priority.

Huang

et al.

[5]

developed

a combined

_priority

abort

and

_priority

inheritance

_protocol,

called conditional

priority

inheritance,

to

_capitalise

on the

_advantages

of

both schemes. The

_protocol

_attempts

to reduce the

blocking

times with

_respect

to PI, and to reduce the

abort rate with

_respect

to PA. When a transaction T is

blocked

_by

a lower

_priority

transaction

T’,

if T’ is near

completion,

it inherits the

_priority

of T;

otherwise,

T’ is aborted. The

_protocol

assumes that the

_length

of a

transaction

_(i.e.

the number of data items accessed

_by

the

transaction)

is known in advance. The

_protocol

has

a threshold

_parameter

h. At the time of a data

conflict,

if the

_remaining

number of data items to be accessed

by

the

_lock-holding

transaction is less than or

_equal

to threshold

_h,

then PI is

_applied;

otherwise,

PA is used.

An extension to PI is the

_priority

_{ceiling protocol}

which bounds the

_blocking

time of

_high

_priority

trans-actions to no more than one transaction execution time

[9, 10].

It eliminates the deadlock

_problem

from PI and

attempts

to reduce the

_{blocking delays}

of

_high

_priority

transactions. The

_’priority

_ceiling’

of a data item is

defined as the

_priority

of the

highest

_priority

transac-tion _{that may have} a lock on that item. In order to

obtain a lock on a data item, the

protocol

_requires

that a transaction T must have a

_priority

strictly higher

than the

_highest

_priority

_ceiling

of data items locked

by

the transactions other than T.

Otherwise,

transac-tion T is blocked

_by

the transaction which holds the lock on the data item of the

_{highest priority}

_ceiling.

In a more recent

work,

we

_provided

a new

concur-rency control

protocol,

called

data-priority-based

locking

protocol,

to _{prove that the real-time}

locking protocol,

can be further

improved

if the data

access

_requirements

of transactions are known in

advance

[13].

Similar to the

_priority

_{ceiling protocol,}

the

_{proposed protocol}

is based on

_prioritising

data

items;

each data item carries a

_priority

_equal

to the

highest

priority

of all transactions

_currently

in the

system

that include the data item in their access lists.

In order to obtain a lock on a data item D, the

_priority

of a transaction T must be

_equal

to the

_priority

of D. Otherwise

_(if

the

_priority

of T is less than that of

D),

transaction T is blocked

_by

the transaction that is

responsible

for the

_priority

of D.

Some variants of the

_optimistic

_concurrency control

protocol

have also been

_developed

and evaluated for time-critical

_{applications.}

Haritsa et al.

_developed

an

optimistic

protocol,

called WAIT-50, which allows for the use of

_priorities

to

_improve

decision

_making

in

resolving

conflicts

[3].

The

_protocol

uses a ’50 per

cent’ rule as follows: the validation check for a

committing

transaction is

_performed

_against

the other active transactions. If a conflict exists and half or more

of the transactions

_conflicting

with the

_committing

transaction are of

higher

_priority,

the transaction is

made to wait for the

_high

_priority

transactions to

complete;

otherwise,

it is allowed to commit while the

conflicting

transactions are aborted.

The

_priority

inversion

_problem

that was defined for

locking

protocols

can also exist in a

_system

that main-tains data

_consistency

_through

use of a

time-stamp-ordering

concurrency control

protocol.

It is

possible

that a

_high

_priority

transaction T is aborted at its

access to a data item, since a lower

_priority

transac-tion

T ;

_carrying

a

_{time-stamp higher}

than the

time-stamp

of _T, has accessed that data item

_previously.

We

proposed

a

_{time-cognisant}

_{concurrency control}

protocol

that

_attempts

to control the

_priority

inversion

problem

of the

_{time-stamp-ordering}

scheme

[13].

The

new

_{protocol categorises}

the transactions into

time-stamp

groups based on their arrival times. The time is

divided into intervals of a certain

_length

and the

trans-actions that arrive at the

_system

within the same

interval are

_placed

in the same

_time-stamp

_group. The

basic idea is to schedule the transactions of the same

time-stamp

group based on their real-time

_priorities.

Each transaction is

_assigned

a two-level

_time-stamp

made _up of a _group

_time-stamp

and a real-time

time-stamp.

The transactions within the same

_time-stamp

group are

_assigned

the same _group

_time-stamp

which

is the arrival time of the first transaction in _{that group.} Real-time

_time-stamps

of transactions within the same

group are determined based on the real-time

_priorities

of transactions. The transaction with the

_highest

priority

obtains the

_largest

real-time

_time-stamp,

so it

cannot be aborted

_by

any other transaction in the same

group in the case of a data access conflict.

An extensive

_exploration

of the issues in

concur-rency control and other

time-cognisant

scheduling

concepts,

such as buffer

_management,

I/O

scheduling,

commitment, etc, is

_provided

in

[14].

4.

Discussion

There is a

_growing

interest in

_applying

the

_principles

and

_techniques

of real-time

_scheduling

to transaction

management

in DBMSs.

_Today,

_many

_application

areas

supported by

a DBMS

(e.g.

information retrieval

systems,

airline reservation

systems,

stock

market,

banking,

etc)

are characterised

by

the

_requirement

of

timely

access to the

_underlying

database. In addition to

_maintaining

database

_consistency,

an essential

scheduling goal

in those

_applications

is to

_satisfy

timing

constraints associated with transactions

accessing

the database.

In this _paper, we introduced the research efforts in

time-constrained transaction

_scheduling.

We

_briefly

reviewed the basic methods used in

_mapping

_timing

constraints of transactions into

_priorities

and the

priority-based

concurrency control

techniques

proposed

to _{control the interaction among}

concur-rently

executing

transactions. We believe

that,

although

some _{progress has been made} towards the

development

of

_{time-cognisant}

_{concurrency control}

protocols,

more

_{general empirical}

work needs to be

performed

to demonstrate the

_practicality

of those

protocols.

As a final

remark,

main _memory databases are

expected

to be

_economically

feasible in the near

future,

due to

_falling

_memory

_prices

and

_growing

memory sizes

[11].

With

memory-resident

databases,

transaction execution time will become more

predictable,

and thus the

_adaptation

of real-time

scheduling techniques

to DBMSs will become much easier. Trends in the

_technology

of main _memory

suggest

that research for the time-critical database

management

should be focused more on main _memory

database

_systems.

Acknowledgement

This work was

_{supported by}

TUBITAK under _grant number

References

[1] R. Abbott and H. Garcia-Molina,

_Scheduling

real-time

transactions: a

_performance

evaluation, ACM

Trans-actions on Database

Systems

17 (1992) 513-560.

[2] J. R. Haritsa, M. _{J. Carey} and M.

_Livny,

Value-Based

Scheduling

in Real-Time Database

_Systems

(TR-1204)

(Department

of

_Computer

Science, _University of

Wisconsin-Madison, 1991).

[3] J. R. Haritsa, M. _{J. Carey} and M. _Livny, Data access

scheduling

in firm real-time database _systems,

Real-Time

_Systems

4 (1992) 203-241.

[4] J.

Huang,

J. A. Stankovic, D.

_Towsley

and K.

Ramamritham,

Experimental

evaluation of real-time transaction

_processing.

In:

_{Proceedings of}

the 10th Real-Time

_{Systems Symposium}

_{(1989) pp.} 144-153.

[5] J.

Huang,

J. A. Stankovic, K. Ramamritham, D.

_Towsley

and B. _{Purimetla, Priority} inheritance in soft real-time

databases, Real-Time

_Systems

4 ₍₁₉₉₂₎ 243-268.

[6] E. D. _Jensen, C. D. Locke and H. Tokuda, A time-driven

scheduling

model for real-time

_operating

_systems. In:

Proceedings of

the 6th Real-Time

_{Systems Symposium}

(1985) pp. 112-122.

[7] K. Ramamritham, Real-time _databases, International

Journal of

Distributed and Parallel Databases 1 (1993)

199-216.

[8] L. Sha, R.

_Rajkumar

and _J.

_Lehoczky,

_Concurrency

control for distributed real-time databases, ACM SIGMOD Record 17 ₍₁₉₈₈₎ 82-98.

[9] L. _Sha, R.

_Rajkumar

and _J.

_Lehoczky,

_Priority

inheri-tance

_protocols:

an

_approach

to real-time

synchroniza-tion, IEEE Transaction on

_Computers

39 (1990)

1175-1185.

[10] L. Sha, R.

_Rajkumar,

S. H. Son and C. H.

_Chang,

A

real-time

_{locking protocol,}

IEEE Transactions on

_Computers

40 (1991) 793-800.

[11] M.

_Singhal,

Issues and

_approaches

to

_design

of

real-time database _systems, ACM SIGMOD Record 17 (1988)

19-33.

[12] J. A. Stankovic and W. Zhao, On real-time transactions,

ACM SIGMOD Record 17 (1988) 4-18.

[13] Ö.

_Ulusoy

and G. G. Belford, Real-time transaction

scheduling

in database _systems,

_{Information Systems}

18 (1993) 559-580.

[14] Ö.

_Ulusoy,

Research Issues in Real-Time Database

Systems

(BU-CEIS-94-32)

(Department

of

_Computer

Engineering

and Information Science, Bilkent