A

FRAMEWORK

FOR

ENFORCEABLE

SPECIFICATION

OF

EXTENDED

TRANSACTION

MODELS

AND

TRANSACTIONAL

WORKFLOWS

DIMITRIOS

GEORGAKOPOULOS

and

MARK

F.

HORNICK

GTE

Laboratories

Incorporated

Waltham

MA

USA

ABSTRACT

A

variety

of

extensions

to

the

traditional

-LRB-

ACID

-RRB-

transaction

model

have

resulted

in

a

plethora

of

extended

transaction

models

-LRB-

ETMs

-RRB-

Many

of

these

ETMs

are

application-specific

i.e.

they

are

designed

to

provide

correctness

guarantees

adequate

for

a

particular

application

but

not

others

Similarly

an

application-specific

ETM

may

impose

restrictions

that

are

unacceptable

in

one

application

yet

required

in

another

To

define

new

ETMs

to

determine

whether

an

ETM

is

appropriate

for

an

application

and

to

integrate

ETMs

to

produce

new

ETMs

we

need

a

framework

for

ETM

specification

and

reasoning

In

this

paper

we

describe

such

a

framework

Our

framework

supports

implementation-independent

specification

of

ETMs

described

in

terms

of

dependencies

between

transactions

Dependencies

are

specified

using

dependency

descriptors

Unlike

other

transaction

specification

frameworks

dependency

descriptors

use

a

common

set

of

primitives

and

are

enforceable

i.e.

can

be

evaluated

at

any

time

during

transaction

execution

to

determine

whether

issued

operations

violate

ETM

specifications

We

discuss

specifications

of

-LRB-

i

-RRB-

structure

dependencies

between

transaction

states

and

-LRB-

ii

-RRB-

correctness

dependencies

for

serializability

various

cooperative

and

temporal

correctness

criteria

and

recoverability

We

give

ETM

specification

examples

for

a

telecommunications

application

illustrating

the

definition

of

a

new

application-specific

ETM

using

our

framework

Introduction

The

need

for

introducing

extended

transaction

models

-LRB-

ETMs

-RRB-

to

support

various

application

requirements

has

been

recognized

for

some

time

and

numerous

ETMs

have

been

proposed

including

-LSB-

-RSB-

ETMs

extend

the

traditional

-LRB-

ACID

-RRB-

transaction

model

to

allow

-LRB-

i

-RRB-

nested

transaction

structure

and/or

transaction

grouping

and

-LRB-

ii

-RRB-

use

of

new

correctness

criteria

for

permitting

functionality

necessary

for

advanced

applications

improving

transaction

throughput

and/or

dealing

with

the

autonomy

of

local

databases

in

a

multidatabase

environment

International

Journal

of

Intelligent

and

Cooperative

Information

Systems

Vol

No.

-LRB-

-RRB-

World

Scientific

Publishing

Company

Received

January

Revised

June

ETMs

proposed

to

allow

advanced

application

functionality

-LRB-

e.g.

permit

transaction

cooperation

-RRB-

and

improve

throughput

-LRB-

e.g.

reduce

transaction

blocking

and

abortion

caused

by

transaction

synchronization

-RRB-

relax

the

atomicity

and

isolation

properties

of

the

ACID

transaction

model

-LSB-

-RSB-

However

many

of

these

extensions

resulted

in

application-specific

ETMs

offering

adequate

correctness

guarantees

in

a

particular

application

but

not

others

Furthermore

an

ETM

may

impose

unacceptable

restrictions

in

one

application

but

these

same

restrictions

may

be

required

by

another

For

example

sagas

-LSB-

-RSB-

can

not

guarantee

database

correctness

in

many

banking

applications

while

nested

transactions

-LSB-

-RSB-

do

not

allow

sharing

of

uncommitted

data

crucial

in

CAD

CAM

applications

If

no

existing

ETM

satisfies

the

requirements

of

an

application

a

new

ETM

must

be

defined

to

do

so

ETMs

introduced

to

deal

with

the

autonomy

of

local

databases

in

a

multidatabase

environment

support

multidatabase

transactions

consisting

of

ACID

transactions

submitted

at

different

local

DBMSs

-LSB-

-RSB-

Since

local

DBMSs

are

autonomous

ETMs

for

multidatabase

transactions

were

created

by

integrating

the

ACID

transaction

models

enforced

by

the

local

DBMSs

Examples

include

global

serializability

discussed

e.g.

in

-LSB-

-RSB-

and

quasi-serializability

discussed

in

-LSB-

-RSB-

Since

multidatabase

ETMs

must

be

designed

to

be

compatible

with

the

transaction

models

of

the

local

DBMSs

these

ETMs

require

all

subtransactions

that

access

local

DBMSs

to

be

ACID

ETM

definition

is

also

required

for

workflow

management

-LSB-

-RSB-

A

workflow

is

a

collection

of

tasks

organized

to

accomplish

some

business

process

Workflows

define

a

task

structure

describing

the

order

of

task

invocation

task

synchronization

and

data-flow

ETMs

are

needed

to

ensure

the

correctness

of

such

workflows

-LSB-

-RSB-

This

involves

mapping

-LRB-

i

-RRB-

workflow

tasks

to

constituent

transactions

of

an

extended

transaction

supported

by

an

ETM

and

-LRB-

ii

-RRB-

workflow

structure

to

an

extended

transaction

structure

supported

by

the

same

ETM

as

-LRB-

i

-RRB-

-LSB-

-RSB-

Workflows

obey

the

correctness

criterion

specified

by

the

ETM

Like

the

ETMs

for

multidatabase

transactions

workflow

ETMs

must

be

compatible

with

the

local

transaction

models

supported

by

the

systems

where

workflow

tasks

are

executed

However

unlike

multidatabase

environments

the

local

systems

that

participate

in

a

workflow

execution

may

not

support

ACID

transactions

Furthermore

workflow

requirements

are

so

diverse

that

no

single

ETM

is

sufficient

to

meet

the

needs

of

all

workflows

Defining

a

new

application-specific

ETM

for

a

workflow

involves

comparing

its

correctness

criterion

with

the

correctness

guarantees

provided

by

local

systems

to

determine

whether

the

ETM

can

be

enforced

This

involves

ETM

definition

comparison

and

possibly

integration

To

define

new

ETMs

to

determine

whether

an

ETM

is

appropriate

for

an

application

to

decide

which

of

the

existing

ETMs

is

best

for

an

application

and

to

integrate

ETMs

to

produce

new

ETMs

we

need

a

framework

for

implementation-independent

specification

of

ETMs

Clearly

using

such

a

framework

to

reason

about

ETMs

is

much

simpler

than

reasoning

in

terms

of

locking

timestamp

ordering

logging

transaction

spawning

and

the

other

heterogeneous

techniques

that

are

used

to

implement

ETMs

This

paper

proposes

such

a

framework

ETMs

are

described

in

terms

of

dependencies

between

the

types

of

transactions

that

these

ETMs

allow

Transaction

dependencies

can

be

viewed

as

constraints

on

the

execution

structure

of

extended

transactions

allowed

by

an

ETM

and

the

correctness

criteria

that

such

transactions

must

satisfy

-LSB-

-RSB-

For

example

a

structural

constraint

on

nested

transactions

is

that

a

parent

can

not

commit

unless

all

its

children

abort

or

commit

Examples

of

correctness

criteria

include

serializability

quasiserializability

-LSB-

-RSB-

cooperative

-LSB-

-RSB-

and

temporal

-LSB-

-RSB-

In

our

framework

transaction

dependencies

are

captured

by

dependency

descriptors

Unlike

other

transaction

specification

frameworks

such

as

ACTA

-LSB-

-RSB-

our

dependency

descriptors

are

enforceable

and

use

a

small

set

of

primitives

Dependency

specifications

are

enforceable

if

they

can

be

evaluated

at

any

time

to

determine

whether

an

execution

-LRB-

possibly

partially

completed

-RRB-

violates

ETM

specifications

This

is

useful

for

enforcing

specifications

either

directly

-LRB-

e.g.

by

a

theorem

prover

-RRB-

or

indirectly

-LRB-

e.g.

by

using

specifications

to

construct

a

conventional

transaction

management

mechanism

-RRB-

An

approach

for

using

ETM

specifications

to

configure

a

run-time

transaction

management

mechanism

that

enforces

various

ETMs

is

discussed

in

-LSB-

-RSB-

This

is

highly

desirable

in

a

Distributed

Object

Management

System

-LSB-

-RSB-

which

must

support

a

variety

of

ETMs

corresponding

to

advanced

applications

and

workflows

Another

important

characteristic

of

our

transaction

specification

framework

is

that

it

requires

only

standard

quantifiers

on

finite

transaction

sets

and

a

single

operator

-LRB-

transitive

closure

-RRB-

We

consider

those

to

be

the

basic

primitives

for

specifying

most

ETMs

The

rest

of

this

paper

is

organized

as

follows

In

Section

we

discuss

transaction

dependencies

In

Section

we

introduce

dependency

descriptors

a

key

concept

of

our

transaction

specification

framework

Specification

of

transaction

structure

-LRB-

state

-RRB-

dependencies

is

discussed

in

Section

Correctness

dependencies

are

described

in

Section

Related

work

and

the

advantages

of

our

framework

are

discussed

in

Section

Transaction

Dependencies

Specification

of

extended

and

multi-system

transactions

is

based

on

the

observation

that

extended

transactions

consist

of

a

set

of

constituent

transactions

and

a

set

of

transaction

dependencies

between

them

Each

constituent

transaction

of

an

extended

transaction

is

either

a

simple

transaction

-LRB-

i.e.

a

transaction

that

has

no

constituent

transactions

-RRB-

or

another

extended

transaction

-LRB-

if

an

ETM

permits

nesting

or

grouping

-RRB-

Each

extended

transaction

T

that

is

not

a

constituent

transaction

of

any

other

transaction

has

the

following

two

kinds

of

transaction

dependencies

Intra-transaction

dependencies

that

define

the

relationships

between

the

constituent

transactions

of

T

Inter-transaction

dependencies

that

define

the

relationships

between

T

and

all

transactions

that

are

not

constituent

transactions

of

T

The

constituent

transactions

of

an

extended

transaction

T

have

only

intra-transaction

dependencies

For

example

consider

nested

transactions

-LSB-

-RSB-

Intra-transaction

dependen

cies

exist

between

a

parent

and

its

child

transactions

and

among

sibling

transactions

Inter-transaction

dependencies

occur

between

top

transactions

-LRB-

i.e.

nested

transactions

that

are

not

constituent

transaction

of

any

other

transaction

-RRB-

To

illustrate

both

intra

and

inter-transaction

dependencies

consider

an

extended

transaction

T

-LRB-

TC

TD

-RRB-

that

performs

provisioning

and

billing

for

a

telecommunications

application

where

TC

-LCB-

-RCB-

is

a

set

of

transactions

that

constitute

T

and

TD

is

a

set

of

transaction

dependencies

between

them

In

particular

suppose

that

T

is

executed

when

a

telephone

company

customer

requests

telephone

service

installation

Transaction

registers

billing

information

in

the

customer

database

and

perform

two

alternative

line

provisioning

tasks

Only

one

of

the

provisioning

tasks

should

be

allowed

to

complete

as

either

will

result

in

a

completed

circuit

i.e.

a

set

of

lines

and

equipment

that

connects

the

customer

to

a

telephone

network

attempts

to

provide

a

connection

by

using

existing

facilities

such

as

lines

and

slots

in

switches

If

succeeds

the

cost

of

provisioning

is

minimal

i.e.

the

requested

connection

is

established

by

allocating

existing

resources

However

a

successful

completion

of

this

activity

may

not

be

possible

if

the

facilities

are

not

available

achieves

the

same

objectives

as

but

involves

physical

installation

of

new

facilities

Thus

has

a

higher

cost

than

Since

is

needed

only

if

fails

is

a

contingency

transaction

-LSB-

-RSB-

There

are

two

types

of

transaction

dependencies

transaction

state

dependencies

and

correctness

dependencies

Transaction

correctness

dependencies

can

be

intra

and

intertransaction

dependencies

while

transaction

state

dependencies

can

be

only

intra-transaction

dependencies

Transaction

state

dependencies

are

conditions

on

transaction

states

that

define

the

execution

structure

of

extended

transactions

Figure

depicts

the

following

intra-transaction

dependencies

that

define

the

execution

structure

of

T

assuming

that

and

can

not

begin

before

commits

and

that

and

can

execute

concurrently

backward-commit-begin

-LRB-

-RRB-

can

not

begin

before

commits

backward-commit-begin

-LRB-

-RRB-

can

not

begin

before

commits

backward-abort-commit

-LRB-

-RRB-

can

not

commit

before

aborts

strong-commit-abort

-LRB-

-RRB-

must

abort

if

commits

forward-commit-begin

-LRB-

-RRB-

can

not

begin

after

has

committed

Note

that

dependencies

and

imply

can

not

commit

after

commits

This

dependency

can

replace

dependencies

and

However

it

allows

to

continue

its

exe

dependency

Figure

Structural

dependencies

of

transaction

T

cution

thereby

holding

resources

or

performing

unnecessary

computations

even

if

has

committed

Correctness

dependencies

specify

which

concurrent

executions

of

extended

transactions

preserve

consistency

and

produce

correct

results

thereby

defining

a

correctness

criterion

Correctness

dependencies

include

Serialization

dependencies

that

specify

whether

the

schedule

of

operations

performed

by

transactions

in

a

set

t

on

a

set

of

objects

O

must

be

serializable

or

whether

the

serialization

order

of

a

transaction

Ti

in

t

must

precede

the

serialization

order

of

another

transaction

Tj

in

t.

Visibility

dependencies

that

define

whether

the

schedule

of

operations

performed

by

transactions

in

a

set

t

on

objects

that

belong

to

a

set

O

must

be

recoverable

cascadeless

strict

rigorous

etc.

-LSB-

-RSB-

Cooperation

dependencies

that

define

whether

transactions

in

a

set

t

may

perform

operations

on

objects

that

belong

to

a

set

O

without

restrictions

-LSB-

-RSB-

Temporal

dependencies

that

specify

whether

transactions

in

a

set

t

must

perform

their

operations

on

objects

that

belong

to

a

set

O

in

a

particular

temporal

order

-LSB-

-RSB-

Correctness

dependencies

may

reflect

application

semantics

or

be

application

independent

To

illustrate

consider

again

the

extended

transaction

T

that

provides

telephone

service

Suppose

that

t

is

the

set

of

transactions

that

performed

operations

on

all

objects

accessed

by

T

The

following

dependencies

are

application

independent

and

sufficient

to

ensure

correctness

inter-transaction

serialization

dependencies

The

schedule

of

operations

performed

by

T

and

those

performed

by

all

committed

transactions

in

t

must

be

serializable

This

dependency

does

not

require

the

constituent

transactions

of

T

to

appear

atomic

to

each

other

intra-transaction

serialization

dependencies

Since

and

can

be

executed

concurrently

the

schedule

of

operations

performed

by

and

must

be

serializable

commits

its

execution

before

and

begin

Thus

need

not

have

correctness

dependencies

While

application-independent

correctness

dependencies

are

sufficient

to

ensure

correctness

they

may

impose

unnecessary

restrictions

For

example

the

two

contingency

transactions

and

need

not

appear

atomic

to

each

other

Removing

the

intra-transaction

serialization

dependencies

between

and

may

result

in

a

situation

in

which

both

transactions

are

able

to

construct

complete

circuits

using

the

same

line

-LRB-

s

-RRB-

and/or

equipment

Since

circuits

require

exclusive

access

to

their

lines

this

will

be

unacceptable

for

many

other

provisioning

transactions

However

the

semantics

of

this

particular

telecommunications

application

permits

any

number

of

alternative

transactions

like

and

as

long

as

only

one

of

them

is

allowed

to

commit

and

use

the

lines

In

the

case

where

correctness

reflects

application

semantics

we

say

that

and

have

an

intra-transaction

coop

eration

dependency

Some

correctness

criteria

proposed

in

the

literature

allow

transaction

cooperation

-LSB-

-RSB-

Correctness

and

state

dependencies

must

be

considered

together

For

example

to

prevent

from

executing

before

the

completion

of

we

can

specify

the

dependency

can

not

begin

before

aborts

In

this

case

intra-transaction

correctness

dependencies

between

and

are

eliminated

We

are

not

aware

of

any

ETM

proposed

in

the

literature

that

can

support

our

telecommunications

transaction

T

Since

the

combination

of

T?s

structure

intra-transaction

cooperation

dependencies

-LRB-

between

and

-RRB-

and

use

of

application-specific

semantics

is

unique

this

is

a

new

ETM

designed

specifically

for

telecommunications

provisioning

and

billing

Dependency

Descriptors

To

specify

dependencies

among

transactions

we

use

dependency

descriptors

which

are

defined

as

a

tuple

of

the

form

-LRB-

Ti

t

O

t

En

Post

-RRB-

Ti

is

a

dependent

transaction

t

is

the

set

of

transactions

that

Ti

depends

on

and

O

is

the

set

of

objects

the

dependency

must

consider

t

together

with

O

define

that

the

dependency

considers

only

operations

performed

by

Ti

and

the

transactions

in

t

on

objects

that

belong

to

O

The

fourth

parameter

of

a

dependency

descriptor

is

a

vector

t

that

contains

any

real-time

intervals

Ti

depends

on

The

last

two

elements

are

logical

predicates

The

postcondition

-LRB-

Post

-RRB-

must

evaluate

to

true

whenever

the

dependency

is

satisfied

The

enabling

condition

-LRB-

En

-RRB-

specifies

when

the

postcondition

must

be

considered

A

dependency

descriptor

can

be

viewed

as

an

integrity

constraint

on

the

execution

of

extended

transactions

A

basic

requirement

for

dependency

specification

is

that

at

any

point

during

the

execution

of

an

extended

transaction

T

T?s

dependency

descriptors

must

reveal

whether

the

execution

that

took

place

until

then

satisfies

T?s

dependencies

However

it

is

not

always

possible

to

determine

whether

a

dependency

is

satisfied

or

not

simply

because

the

available

execution

schedule

does

not

provide

enough

information

For

example

consider

the

dependency

can

not

begin

before

commits

where

depends

on

Until

begins

there

is

not

enough

information

in

the

schedule

to

determine

whether

the

dependency

is

satisfied

To

prevent

dependency

descriptor

evaluation

until

there

is

enough

information

available

the

enabling

condition

En

must

be

set

to

begin

While

En

is

false

the

dependency

descriptor

evaluates

to

don?t

know

The

postcondition

is

evaluated

if

and

only

if

the

enabling

condition

becomes

true

If

the

postcondition

evaluates

to

false

the

dependency

is

violated

otherwise

it

is

satisfied

Figure

illustrates

the

results

of

the

evaluation

of

a

dependency

descriptor

with

respect

to

the

value

of

its

enabling

condition

and

postcondition

T

i

t

O

t

En

Pos

t

-LRB-

-RRB-

iff

En

tr

ue

and

Pos

t

f

al

s

e

iff

En

tr

ue

and

Pos

t

tr

ue

iff

En

f

a

l

se

violated

don?t

know

satisfied

Figure

Evaluation

of

a

dependency

specification

Due

to

the

existence

of

enabling

conditions

dependency

descriptors

provide

reliable

true

and

false

evaluation

results

This

allows

determining

specification

violations

as

soon

as

the

enabling

condition

of

a

dependency

descriptor

becomes

true

purging

descriptors

of

satisfied

state

dependencies

as

soon

as

their

enabling

conditions

becomes

true

and

their

post

conditions

have

been

evaluated

dependency

descriptor

evaluation

to

take

place

before

the

finite

execution

schedule

is

available

dependency

descriptors

that

can

be

used

directly

to

synchronize

transaction

execution

Although

many

ETMs

are

time

independent

there

are

models

such

as

the

flexible

transactions

of

-LSB-

-RSB-

that

allow

the

definition

of

temporal

predicates

on

transaction

states

If

a

dependency

descriptor

includes

temporal

predicates

the

t

vector

contains

the

real-time

intervals

referenced

by

them

For

example

the

vector

t

of

the

dependency

descriptor

of

Ti

must

begin

by

contains

In

the

rest

of

this

paper

we

omit

t?s

from

dependency

descriptors

that

do

not

have

temporal

predicates

In

the

following

sections

we

discuss

the

specification

and

implementation

of

state

and

correctness

dependencies

Transaction

State

Dependencies

Transaction

state

dependencies

or

simply

state

dependencies

associate

the

states

of

different

transactions

A

state

dependency

that

associates

only

a

pair

of

transaction

states

is

a

simple

state

dependency

State

dependencies

that

associate

more

than

two

transaction

states

are

complex

state

dependencies

Simple

State

Dependencies

We

define

three

kinds

of

state

dependencies

backward

forward

and

strong

Backward

state

dependencies

between

a

pair

of

transactions

Ti

and

Tj

impose

conditions

of

the

following

type

Ti

can

not

enter

state

X

before

Tj

has

entered

state

Y

Such

dependencies

are

defined

by

a

descriptor

of

the

form

-LRB-

Ti

-LCB-

Tj

-RCB-

O

Ti.state

X

Y

-LRB-

Tj

-RRB-

X

-LRB-

Ti

-RRB-

-RRB-

The

set

of

transactions

that

Ti

depends

on

includes

only

Tj

and

O

is

the

set

of

all

objects

Ti.state

X

indicates

that

the

current

state

of

Ti

is

X.

X

-LRB-

Ti

-RRB-

denotes

the

operation

that

changes

the

state

of

Ti

to

X

The

difference

between

Ti.state

X

and

X

-LRB-

Ti

-RRB-

is

that

the

execution

schedule

contains

X

-LRB-

Ti

-RRB-

even

if

Ti

leaves

state

X

We

use

to

specify

the

order

of

operations

in

the

execution

schedule

The

dependency

descriptor

is

enabled

when

Ti

enters

state

X

The

dependency

is

satisfied

only

if

Tj

has

entered

state

Y

before

Ti

enters

state

X

i.e.

Tj

has

performed

Y

-LRB-

Tj

-RRB-

before

Ti

issues

X

-LRB-

Ti

-RRB-

Backward

state

dependency

evaluation

results

are

illustrated

in

Table

A

mark

is

used

to

indicate

if

X

-LRB-

Ti

-RRB-

and

Y

-LRB-

Tj

-RRB-

are

present

in

the

schedule

and

whether

Tj

has

performed

Y

-LRB-

Tj

-RRB-

before

Ti

issues

X

-LRB-

Ti

-RRB-

For

example

the

dependency

can

not

begin

before

commits

is

specified

by

-LRB-

-LCB-

-RCB-

O

Begin

Commit

-LRB-

-RRB-

Begin

-LRB-

-RRB-

-RRB-

and

is

satisfied

only

if

has

performed

Commit

-LRB-

-RRB-

before

issues

Begin

-LRB-

-RRB-

Forward

state

dependencies

express

conditions

of

the

following

type

Ti

can

not

enter

state

X

after

Tj

has

entered

state

Y

They

are

specified

as

follows

-LRB-

Ti

-LCB-

Tj

-RCB-

O

Ti.state

X

-LRB-

Y

-LRB-

Tj

-RRB-

X

-LRB-

Ti

-RRB-

-RRB-

-RRB-

A

forward

state

dependency

is

satisfied

if

Ti

has

performed

X

-LRB-

Ti

-RRB-

before

Tj

issues

Y

-LRB-

Tj

-RRB-

or

if

Tj

has

not

performed

Y

-LRB-

Tj

-RRB-

Table

illustrates

the

results

of

forward

state

dependency

descriptor

evaluations

For

example

the

dependency

can

not

begin

after

has

committed

is

captured

by

the

following

descriptor

-LRB-

-LCB-

-RCB-

O

Begin

-LRB-

Commit

-LRB-

-RRB-

Begin

-LRB-

-RRB-

-RRB-

-RRB-

The

dependency

is

satisfied

if

either

has

performed

Begin

-LRB-

-RRB-

before

issues

Commit

-LRB-

-RRB-

or

has

not

performed

Commit

-LRB-

-RRB-

Strong

state

dependencies

express

conditions

of

the

following

type

Ti

must

enter

state

X

if

Tj

has

entered

state

Y

They

are

defined

by

the

following

descriptor

-LRB-

Ti

-LCB-

Tj

-RCB-

O

Tj.state

Y

X

-LRB-

Ti

-RRB-

-RRB-

Consider

the

dependency

must

abort

if

commits

specified

by

-LRB-

-LCB-

-RCB-

O

Commit

Abort

-LRB-

-RRB-

-RRB-

This

dependency

is

satisfied

if

commits

and

either

-LRB-

i

-RRB-

Table

Evaluation

of

backward

state

dependencies

X

-LRB-

Ti

-RRB-

Y

-LRB-

Tj

-RRB-

Y

-LRB-

Tj

-RRB-

X

-LRB-

Ti

-RRB-

-LRB-

Ti

-LCB-

Tj

-RCB-

O

Ti.state

X

Y

-LRB-

Tj

-RRB-

X

-LRB-

Ti

-RRB-

-RRB-

don?t

know

don?t

know

violated

violated

satisfied

Table

Evaluation

of

forward

state

dependencies

X

-LRB-

Ti

-RRB-

Y

-LRB-

Tj

-RRB-

Y

-LRB-

Tj

-RRB-

X

-LRB-

Ti

-RRB-

-LRB-

Ti

-LCB-

Tj

-RCB-

O

Ti.state

X

-LRB-

Y

-LRB-

Tj

-RRB-

X

-LRB-

Ti

-RRB-

-RRB-

-RRB-

don?t

know

don?t

know

satisfied

satisfied

violated

has

aborted

or

-LRB-

ii

-RRB-

will

eventually

abort

Although

-LRB-

i

-RRB-

can

be

determined

immediately

-LRB-

ii

-RRB-

may

never

happen

-LRB-

e.g.

never

executes

-RRB-

To

avoid

the

uncertainty

as

to

whether

a

strong

state

dependency

is

satisfied

strong

state

dependency

descriptors

can

not

be

used

to

specify

that

a

transaction

must

eventually

abort

This

can

be

specified

by

a

weaker

forward

state

dependency

such

as

can

not

commit

after

commits

The

same

problem

as

for

abort

exists

for

eventual

begin

prepare

or

commit

To

deal

with

operations

whose

execution

has

not

yet

occurred

and

may

never

occur

strong

state

dependencies

must

-LRB-

implicitly

or

explicitly

-RRB-

specify

the

time

boundaries

within

which

they

require

the

occurrence

of

the

operation

that

will

satisfy

them

In

particular

strong

state

dependencies

may

have

-LRB-

i

-RRB-

an

immediate

operational

effect

or

-LRB-

ii

-RRB-

an

enabling

condition

augmented

with

a

temporal

predicate

For

example

consider

again

must

abort

if

commits

If

commits

and

has

not

aborted

we

can

immediately

force

to

abort

Alternatively

if

the

enabling

condition

is

augmented

with

time

must

be

later

than

t

the

dependency

descriptor

will

not

be

enabled

until

t

-LRB-

even

if

commits

before

t

-RRB-

Although

the

dependency

descriptors

of

state

dependencies

can

be

thought

of

as

a

variation

of

temporal

logic

their

expressive

power

is

intentionally

limited

to

what

is

necessary

to

capture

state

dependencies

An

advantage

of

our

formalism

-LRB-

in

particular

of

having

an

enabling

condition

and

restricted

expressive

power

-RRB-

is

that

state

dependency

descriptors

can

be

directly

evaluated

to

enforce

the

dependencies

they

specify

It

is

important

to

notice

that

some

state

dependencies

may

not

be

enforceable

For

example

since

a

transaction

commit

can

not

be

guaranteed

it

may

be

impossible

to

enforce

a

strong

dependency

such

as

must

commit

if

aborts

In

addition

forward

and

backward

dependencies

requiring

that

a

transaction

can

not

abort

may

not

be

possible

to

enforce

a

transaction

may

choose

to

abort

or

the

system

where

the

transaction

executes

may

unilaterally

abort

it

e.g.

as

a

result

of

a

local

deadlock

Complex

State

Dependencies

Complex

state

dependencies

are

compositions

of

simple

and

possibly

other

complex

state

dependencies

There

are

two

basic

categories

of

dependency

compositions

The

first

category

of

dependency

composition

produces

a

complex

dependency

that

is

satisfied

if

and

only

if

all

dependencies

of

which

it

is

composed

are

satisfied

For

example

consider

again

our

telecommunications

example

The

complex

dependency

that

defines

that

can

not

begin

before

commits

and

in

addition

can

not

begin

after

has

committed

is

specified

by

the

following

dependency

descriptor

-LRB-

T

-LCB-

-RCB-

O

Begin

-LSB-

Commit

-LRB-

-RRB-

Begin

-LRB-

-RRB-

-RSB-

-LSB-

Commit

-LRB-

-RRB-

Begin

-LRB-

-RRB-

-RSB-

-RRB-

The

second

category

of

dependency

composition

produces

a

complex

dependency

that

is

satisfied

if

at

least

one

of

the

dependencies

from

which

it

was

composed

is

satisfied

For

example

suppose

that

a

simple

transaction

has

been

added

to

the

set

of

transactions

-LCB-

-RCB-

that

constitute

transaction

T

in

the

telecommunications

example

Transaction

updates

a

directory

assistance

database

once

the

line

provisioning

for

circuits

has

been

successfully

completed

has

the

following

dependencies

-LRB-

i

-RRB-

can

not

begin

before

commits

and

-LRB-

ii

-RRB-

can

not

begin

before

commits

Since

only

one

of

the

provisioning

transactions

will

be

allowed

to

commit

the

composition

of

these

dependencies

must

produce

a

complex

dependency

that

requires

that

at

least

one

of

the

dependencies

above

is

satisfied

This

complex

dependency

is

specified

by

the

following

dependency

descriptor

-LRB-

-LCB-

-RCB-

O

Begin

-LSB-

Commit

-LRB-

-RRB-

Begin

-LRB-

-RRB-

-RSB-

-LSB-

Commit

-LRB-

-RRB-

Begin

-LRB-

-RRB-

-RSB-

-RRB-

Complex

dependencies

that

may

result

from

arbitrary

compositions

of

simple

and/or

complex

state

dependencies

are

discussed

further

in

-LSB-

-RSB-

Correctness

Dependencies

In

this

section

we

discuss

correctness

dependencies

and

their

specification

A

correctness

criterion

determines

the

execution

schedules

that

produce

correct

results

and

do

not

violate

object

consistency

A

basic

approach

for

specifying

correctness

criteria

is

to

do

so

in

terms

of

transaction

schedules

that

are

known

to

be

correct

Since

such

schedules

preserve

correctness

concurrent

executions

that

are

-LRB-

in

some

sense

-RRB-

equivalent

to

correct

executions

are

also

correct

and

should

be

allowed

by

the

system

For

example

serializability

theory

considers

serial

executions

-LRB-

i.e.

executions

in

which

transactions

do

not

interleave

-RRB-

to

be

correct

Since

serial

executions

maintain

correctness

any

execution

that

is

equivalent

to

a

serial

execution

also

preserves

consistency

Conflict-based

correctness

criteria

consider

that

operations

pi

and

qj

performed

by

two

different

transactions

Ti

and

Tj

conflict

in

a

schedule

H

if

their

execution

order

is

important

for

determining

whether

H

is

equivalent

to

a

schedule

known

to

be

correct

Depending

on

the

semantic

and/or

temporal

information

taken

into

account

by

a

correctness

criterion

conflicts

are

defined

differently

Conflict

definition

by

serializability

Traditional

-LRB-

conflict

-RRB-

serializability

theory

-LSB-

-RSB-

considers

that

two

operations

pi

and

qj

conflict

if

they

are

performed

on

the

same

object

and

at

least

one

of

them

is

a

write

operation

That

is

serializability

takes

into

account

only

syntactic

information

in

determining

conflicts

-LRB-

i.e.

whether

operations

are

reads

or

writes

-RRB-

To

capture

this

in

the

following

we

assume

that

object

operations

have

an

objectprovided

property

that

reveals

if

the

operation

changes

the

state

of

the

object

on

which

it

is

performed

In

particular

we

consider

that

the

type

of

pi

-LRB-

ox

-RRB-

is

write

-LRB-

pi

-LRB-

ox

-RRB-

w

-RRB-

if

the

execution

of

an

operation

pi

of

transaction

Ti

changes

the

state

of

object

o

x

without

reading

it

The

type

of

pi

-LRB-

ox

-RRB-

is

read

-LRB-

pi

-LRB-

ox

-RRB-

r

-RRB-

if

pi

only

reads

the

state

of

ox

If

pi

both

reads

and

changes

the

state

of

ox

it

is

both

a

read

and

a

write

Conflicts

are

defined

by

a

conflict

table

which

is

a

relation

that

contains

an

entry

-LRB-

p

q

-RRB-

for

each

pair

of

conflicting

operations

p

and

q.

Each

object

ox

must

be

associated

a

with

a

conflict

table

we

refer

to

as

ox.conflict

table

To

define

that

operations

p

and

q

supported

a

For

efficiency

reasons

several

objects

a

class

of

objects

or

even

several

objects

and

classes

may

be

associated

with

the

same

conflict

table

This

issue

is

discussed

further

in

-LSB-

-RSB-

by

ox

conflict

an

entry

-LRB-

p

q

-RRB-

should

be

inserted

in

ox.conflict

table

If

-LRB-

p

q

-RRB-

is

in

the

conflict

table

of

ox

p

and

q

conflict

The

conflict

table

of

an

object

ox

is

either

an

object-specific

conflict

table

or

a

default

conflict

table

Object-specific

conflict

tables

are

provided

by

the

object

designerb

The

default

conflict

table

is

used

by

objects

whose

object

designer

has

not

provided

a

conflict

table

The

default

conflict

table

for

serializability

is

defined

as

follows

The

definition

of

conflicts

above

is

too

generic

in

its

treatment

of

operations

More

specific

definitions

of

conflicts

can

be

used

in

object-specific

conflict

tables

Three

notions

of

conflicts

that

consider

the

semantics

of

the

operations

-LRB-

and

possibly

their

return

values

-RRB-

have

been

proposed

in

the

literature

commutativity

-LSB-

-RSB-

invalidation

-LSB-

-RSB-

and

recoverability

-LSB-

-RSB-

As

an

example

of

conflict

definition

that

takes

into

account

operation

semantics

consider

using

commutativity

to

define

the

conflict

table

of

a

set

object

Commutativity

states

that

two

operations

conflict

-LRB-

do

not

commute

-RRB-

if

executing

them

in

any

order

does

not

always

produce

the

same

results

and

the

same

final

object

state

A

set

object

supports

the

following

three

operations

Insert

and

Delete

with

write

and

Member

which

tests

for

set

membership

with

read

Since

Insert

operations

are

writes

on

the

same

object

the

default

conflict

table

defines

that

if

such

operations

are

performed

by

different

transactions

they

conflict

Commutativity

defines

that

due

to

their

semantics

Insert

operations

commute

-LRB-

do

not

conflict

-RRB-

Conflict

tables

provided

by

object

designers

may

use

any

conflict

notion

that

considers

operation

semantics

to

allow

more

concurrency

Furthermore

object

designers

may

provide

conflict

tables

that

capture

application-specific

conflict

definitions

Various

correctness

criteria

and

corresponding

conflict

tables

are

discussed

in

the

rest

of

this

paper

Conflict

definition

by

temporal

correctness

criteria

Temporal

correctness

criteria

define

conflicts

the

same

way

as

serializability

However

unlike

serializability

which

considers

all

schedules

equivalent

to

a

serial

schedule

to

be

correct

temporal

correctness

criteria

consider

schedules

correct

only

if

they

are

equivalent

to

one

specific

serial

schedule

-LSB-

-RSB-

As

an

example

of

a

temporal

conflict

consider

a

transaction

Ti

that

changes

the

interest

rates

in

a

bank

and

Tj

that

computes

the

interest

earned

by

the

bank

accounts

To

ensure

correctness

Ti

must

perform

its

write

operations

before

Tj

reads

the

new

interest

rate

Serializability

may

allow

Tj

to

read

the

interest

rate

before

Ti

updates

it

which

will

produce

incorrect

interest

deposits

b

The

object

designer

is

the

individual

or

group

of

individuals

who

define

the

state

and

behavior

of

objects

-LRB-

e.g.

by

defining

class

definitions

-RRB-

and

who

implement

object

behavior

-LRB-

e.g.

by

coding

operation

methods

-RRB-

The

individual

in

this

role

must

know

the

details

of

the

object

model

and

the

capabilities

of

the

underlying

object

system

-LRB-

e.g.

Smalltalk

C++

etc.

-RRB-

-LRB-

pi

-LRB-

ox

-RRB-

qj

-LRB-

ox

-RRB-

-RRB-

ox.conflict

table

true

-LSB-

pi

-LRB-

ox

-RRB-

w

-RSB-

-LSB-

qj

-LRB-

ox

-RRB-

w

-RSB-

false

otherwise

Conflict

definition

by

cooperative

correctness

criteria

Cooperative

correctness

criteria

-LSB-

-RSB-

use

less

restrictive

notions

of

conflicts

that

take

into

account

transaction

semantics

For

example

since

only

one

of

the

provisioning

transactions

and

in

our

example

will

be

allowed

to

commit

only

the

operations

that

allocate

lines

and

slots

from

that

transaction

will

take

effect

Based

on

this

fact

and

should

not

be

considered

as

conflicting

However

the

same

operations

performed

by

another

pair

of

transactions

may

conflict

To

define

that

operations

p

and

q

supported

by

an

object

ox

do

not

conflict

if

they

are

performed

by

specific

transactions

but

conflict

if

they

are

performed

by

all

other

transactions

the

conflict

table

entries

defined

by

serializability

must

be

extended

to

the

entries

of

the

form

-LRB-

p

q

CP

-RRB-

in

which

CP

is

a

conflict

predicate

defined

over

the

set

of

transactions

that

perform

p

and

q.

For

example

if

p

and

q

conflict

for

all

transactions

t

-LRB-

as

in

serializability

-RRB-

this

is

defined

by

an

entry

-LRB-

p

q

true

-RRB-

or

simply

-LRB-

p

q

-RRB-

inserted

in

ox.conflict

table

Suppose

that

due

to

their

semantics

transactions

in

sets

tp

and

tq

do

not

conflict

if

they

perform

operations

p

and

q

This

is

specified

by

-LRB-

re

-RRB-

defining

conflict

table

entries

as

follows

-LRB-

pi

qj

Ti

t-tp

Tj

t-tq

-RRB-

Sets

of

transactions

that

are

not

allowed

to

cooperate

such

as

t-tp

and

t-tq

are

usually

defined

using

-LRB-

possibly

application-specific

-RRB-

transaction

types

This

is

discussed

further

in

Section

In

the

following

subsections

we

derive

specifications

for

serializability

cooperative

and

temporal

correctness

criteria

To

specify

a

correctness

criterion

C

we

formally

define

the

transaction

execution

order

it

permits

This

involves

-LRB-

i

-RRB-

specifying

possible

transaction

precedence

orders

using

the

conflict

table

-LRB-

s

-RRB-

of

the

objects

and

-LRB-

ii

-RRB-

specifying

a

set

of

predicates

that

restrict

possible

transaction

precedence

orders

to

those

allowed

by

C.

All

specifications

require

a

single

operator

-LRB-

transitive

closure

-RRB-

and

standard

quantifiers

on

finite

sets

of

transactions

and

objects

Specifications

of

Serialization

-LRB-

SR

-RRB-

Dependencies

The

specification

of

SR

dependencies

is

based

on

the

following

observations

conflicts

define

precedence

relations

between

transactions

and

serializability

is

violated

if

a

committed

transaction

indirectly

conflicts

with

itself

i.e.

its

precedence

relation

contains

itself

Let

H

be

a

schedule

over

a

set

of

transactions

t

-LCB-

Tk

-RCB-

H

defines

an

order

on

the

operations

performed

by

the

transactions

in

t.

Conflicting

operations

in

H

define

a

precedence

relation

between

transactions

in

t

A

transaction

Ti

directly

SR-precedes

Tj

in

H

-LRB-

denoted

by

Ti

SR

-LRB-

t

O

-RRB-

Tj

-RRB-

iff

Ti

issues

an

operation

pi

-LRB-

ox

-RRB-

that

conflicts

with

an

operation

qj

-LRB-

ox

-RRB-

of

Tj

in

H

pi

-LRB-

ox

-RRB-

precedes

qj

-LRB-

ox

-RRB-

in

H

and

Ti

and

Tj

are

non-aborted

transactions

Ti

SR

-LRB-

t

O

-RRB-

Tj

true

false

otherwise

pi

-LRB-

ox

-RRB-

Ti

qj

-LRB-

ox

-RRB-

Tj

Ti

Tj?t

i

j

ox?O

-LSB-

pi

-LRB-

ox

-RRB-

qj

-LRB-

ox

-RRB-

-RSB-

-LSB-

-LRB-

pi

-LRB-

ox

-RRB-

qj

-LRB-

ox

-RRB-

-RRB-

ox.conflict

table

-RSB-

-LSB-

aborti

abortj

H

-RSB-

Indirect

SR-precedence

between

Ti

and

Tj

is

determined

through

direct

and

indirect

SR-precedence

of

other

transactions

in

t

as

follows

Therefore

the

transitive

closure

of

the

SR-precedence

relation

determines

whether

Ti

SR-precedes

directly

or

indirectly

Tj

in

H

Ti

SR

-LRB-

t

O

-RRB-

Tj

n?N?Ti

SRn

-LRB-

t

O

-RRB-

Tj

where

N

is

the

set

of

positive

integers

For

example

consider

the

following

schedule

-LRB-

ox

-RRB-

-LRB-

ox

-RRB-

-LRB-

oy

-RRB-

-LRB-

oy

-RRB-

-LRB-

ox

-RRB-

-LRB-

oz

-RRB-

-LRB-

oz

-RRB-

-LRB-

oz

-RRB-

Assuming

the

default

read/write

conflicts

-LRB-

t

O

-RRB-

holds

because

of

the

conflict

between

-LRB-

oy

-RRB-

and

-LRB-

oy

-RRB-

-LRB-

t

O

-RRB-

is

true

due

to

the

following

conflicts

-LRB-

oz

-RRB-

with

-LRB-

oz

-RRB-

and

-LRB-

oz

-RRB-

with

-LRB-

oz

-RRB-

-LRB-

t

O

-RRB-

holds

since

both

-LRB-

t

O

-RRB-

and

-LRB-

t

O

-RRB-

hold

Finally

the

closure

-LRB-

t

O

-RRB-

holds

since

-LRB-

t

O

-RRB-

holds

Let

tc

be

the

set

-LCB-

Ti

commit

-LRB-

Ti

-RRB-

H

-RCB-

of

all

committed

transactions

in

H.

H

is

serializable

if

each

transaction

Ti

in

tc

does

not

SR-precede

itself

i.e.

the

transitive

closure

of

the

Ti

with

itself

does

not

hold

Ti

tc

-LSB-

Ti

SR

-LRB-

tc

O

-RRB-

Ti

-RSB-

To

preserve

serializability

in

a

schedule

H

every

transaction

Ti

must

satisfy

the

following

serialization

cycle

dependencies

involving

all

committed

transactions

in

H

Ti

t

-LRB-

Ti

tc-Ti

O

Ti.state

Commit

-LSB-

Ti

SR

-LRB-

tc

O

-RRB-

Ti

-RSB-

-RRB-

If

any

of

the

dependencies

above

are

violated

serializability

is

also

violated

However

if

an

individual

dependency

descriptor

is

satisfied

this

does

not

imply

that

serializability

is

preserved

It

ensures

only

that

Ti

has

not

performed

conflicting

operations

that

form

cycles

To

ensure

the

serializability

of

H

all

transactions

in

tc

must

have

dependency

descriptors

similar

to

those

above

and

all

such

dependencies

must

be

satisfied

For

example

suppose

that

tc

is

the

set

of

committed

transactions

in

H

that

does

not

include

the

constituent

transactions

and

of

our

telecommunications

transaction

T

The

inter-transaction

serialization

cycle

dependencies

between

the

transactions

in

tc

and

the

constituent

transactions

of

T

are

defined

by

the

following

descriptors

-LRB-

TC

denotes

the

set

-LCB-

-RCB-

-RRB-

Ti

TC

-LRB-

Ti

tc

O

Ti.state

Commit

-LSB-

Ti

SR

-LRB-

tc

O

-RRB-

Ti

-RSB-

-RRB-

This

allows

the

constituent

transactions

of

T

to

participate

in

cycles

involving

constituent

transactions

of

T

but

no

other

transactions

The

following

inter-transaction

dependency

descriptor

specifies

that

transactions

other

than

T

can

not

be

involved

in

any

serialization

cycles

Tj

TC

-LRB-

Tj,tc-Tj

O

Tj.state

Commit

-LSB-

Tj

SR

-LRB-

tc

O

-RRB-

Tj

-RSB-

-RRB-

The

serialization

cycle

dependencies

we

have

discussed

so

far

do

not

explicitly

define

the

serialization

order

of

transactions

This

is

required

by

some

correctness

criteria

such

as

Ti

SRn

-LRB-

t

O

-RRB-

Tj

true

false

otherwise

Ti

SR

-LRB-

t

O

-RRB-

Tj

-LSB-

Tk?T

Ti

-LRB-

t

O

-RRB-

Tk

Tk

-LRB-

t

O

-RRB-

Tj

-RSB-

n

cooperative

correctness

discussed

in

the

following

section

We

refer

to

such

dependencies

as

serialization

order

dependencies

A

serialized

before

dependency

between

transactions

Ti

and

Tj

in

a

schedule

H

-LRB-

denoted

by

Ti

SRTj

-RRB-

is

defined

by

the

following

dependency

descriptor

-LRB-

Ti

tc-Ti

O

Ti.state

Commit?Tj.state

Commit

-LSB-

Tj

SR

-LRB-

tc

O

-RRB-

Ti

Ti

SR

-LRB-

tc

O

-RRB-

Ti

-RSB-

-RRB-

A

serialized

after

dependency

between

Ti

and

Tj

-LRB-

Ti

SR

Tj

-RRB-

is

defined

similarly

Specification

of

Cooperative

Correctness

Criteria

Cooperative

correctness

criteria

-LSB-

-RSB-

allow

compatible

transactions

to

cooperate

e.g.

to

repeatedly

read

and

write

specific

objects

without

restrictions

Compatible

transactions

are

specified

by

breakpoints

-LRB-

or

by

compatibility

sets

which

are

similar

to

breakpoints

-RRB-

According

to

the

breakpoint

model

a

transaction

is

modeled

as

consisting

of

steps

Each

step

-LRB-

denoted

by

S

-RRB-

consists

of

a

sequence

of

atomic

operations

and

a

breakpoint

-LRB-

denoted

by

B

-RRB-

at

the

end

of

these

operations

A

breakpoint

defined

within

a

transaction

represents

a

point

in

its

execution

at

which

other

transactions

can

interleave

For

example

consider

the

following

transactions

Ti

Sij

Bij

Sij

Bij

Sin

Bin

Tk

Skl

Bkl

S

km

Bkm

Associated

with

each

breakpoint

Bij

in

a

transaction

Ti

is

a

transaction

set

ts

-LRB-

Bij

-RRB-

that

contains

the

set

of

transaction

types

-LRB-

e.g.

the

type

of

Tk

is

denoted

by

type

-LRB-

Tk

-RRB-

-RRB-

that

are

allowed

to

interleave

at

Bij

For

example

if

ts

-LRB-

Bij

-RRB-

contains

type

-LRB-

Tk

-RRB-

then

transaction

Tk

is

allowed

to

interrupt

transaction

Ti

at

breakpoint

Bij

Next

we

discuss

two

alternative

correctness

specifications

that

allow

the

same

schedules

Specification

of

an

ETM

for

cooperative

extended

transactions

This

involves

viewing

steps

as

simple

atomic

transactions

and

the

transactions

the

steps

belong

to

as

extended

transactions

For

example

according

to

this

ETM

Ti

above

is

an

extended

transaction

that

consists

of

a

set

of

simple

transactions

-LCB-

Sin

-RCB-

and

a

set

of

dependencies

specified

in

terms

of

breakpoints

To

derive

specifications

of

such

extended

transactions

we

convert

breakpoint

specifications

to

corresponding

dependency

descriptors

To

illustrate

such

mappings

consider

the

breakpoint

Bij

of

transaction

Ti

Suppose

that

Bij

specifies

that

transactions

of

type

X

are

the

only

transactions

that

can

interrupt

Ti

at

Bij

and

that

no

other

transactions

can

interrupt

Ti

at

any

other

breakpoint

Under

these

assumptions

Sij

Sij

Sin

have

the

following

serialization

order

dependencies

transactions

of

type

X

can

be

serialized

before

and

Sin

or

transactions

of

type

X

can

be

serialized

after

and

Sin

or

transactions

of

type

X

can

be

serialized

after

S

ij

and

before

Sij

Sin

Dependencies

and

above

specify

serializable

schedules

Dependency

specifies

correct

non-serializable

schedules

-LRB-

relatively

consistent

schedules

in

-LSB-

-RSB-

-RRB-

The

following

cooperative

dependency

descriptors

correspond

to

the

breakpoint

specifications

of

Bij

and

are

stated

in

terms

of

the

serialized

before

-LRB-

SR

-RRB-

and

serialized

after

-LRB-

SR

-RRB-

dependency

descriptors

defined

in

Section

Tk

-LCB-

P

type

-LRB-

P

-RRB-

X

-RCB-

-LSB-

ns

-LRB-

Tk

SR

Sis

-RRB-

-RSB-

-LSB-

ns

-LRB-

Tk

SR

Sis

-RRB-

-RSB-

-LSB-

-LRB-

js

-LRB-

Tk

SR

Sis

-RRB-

-RRB-

-LRB-

ns

j

-LRB-

Tk

SR

Sis

-RRB-

-RRB-

-RSB-

Adding

more

transactions

in

the

same

breakpoint

requires

the

addition

of

similar

dependency

descriptors

for

each

additional

transaction

type

More

specifically

if

Bij

contains

type

-LRB-

-RRB-

type

-LRB-

-RRB-

type

-LRB-

Tr

-RRB-

-LRB-

i.e.

ts

-LRB-

Bij

-RRB-

-LCB-

type

-LRB-

-RRB-

type

-LRB-

-RRB-

type

-LRB-

Tr

-RRB-

-RCB-

-RRB-

the

following

cooperative

dependency

descriptors

correspond

to

this

breakpoint

specification

Tk

-LCB-

P

type

-LRB-

P

-RRB-

ts

-LRB-

Bij

-RRB-

-RCB-

-LSB-

ns

-LRB-

Tk

SR

Sis

-RRB-

-RSB-

-LSB-

ns

-LRB-

Tk

SR

Sis

-RRB-

-RSB-

-LSB-

-LRB-

js

-LRB-

Tk

SR

Sis

-RRB-

-RRB-

-LRB-

ns

j

-LRB-

Tk

SR

Sis

-RRB-

-RRB-

-RSB-

Adding

transactions

to

other

breakpoints

results

in

a

similar

dependency

specification

for

each

breakpoint

To

capture

the

fact

that

the

two

provisioning

transactions

and

in

our

telecommunications

example

can

cooperate

without

violating

correctness

we

can

define

cooperative

intra-transaction

dependencies

similar

to

those

above

In

terms

of

the

breakpoint

model

discussed

above

this

can

be

thought

of

as

if

each

operation

of

that

allocates

lines

or

slots

is

a

step

with

a

breakpoint

containing

and

vice

versa

Specification

of

an

ETM

for

cooperative

simple

transactions

The

approach

just

discussed

requires

representing

the

provisioning

transactions

and

as

complex

transactions

An

alternative

solution

is

to

specify

the

allowed

cooperation

between

simple

transactions

at

the

conflict

table

level

To

illustrate

this

consider

the

provisioning

transactions

and

of

the

telecommunications

transaction

T

In

addition

consider

a

Facility

-LRB-

Fac

-RRB-

object

-LRB-

e.g.

line

or

slot

object

-RRB-

with

a

state

variable

circuitID

and

operations

usedBy

allocFac

and

deallocFac

The

circuitID

variable

of

a

Fac

object

indicates

whether

the

facility

has

been

allocated

If

allocated

it

records

the

ID

of

the

circuit

that

uses

the

facility

Operation

usedBy

simply

reads

the

circuitID

variable

allocFac

records

the

ID

of

the

circuit

that

uses

the

facility

and

deallocFac

sets

the

circuitID

variable

to

indicate

the

facility

is

free

Assuming

serializability

as

our

correctness

criterion

and

that

Fac

object

operations

are

atomic

Fac

objects

have

a

conflict

table

where

all

operation

pairs

except

-LRB-

usedBy

usedBy

-RRB-

conflict

As

we

discussed

earlier

both

provisioning

transactions

and

construct

the

same

circuit

Provisioning

transaction

-LRB-

-RRB-

allocates

facilities

that

are

either

free

or

have

been

previously

allocated

by

-LRB-

-RRB-

Facilities

allocated

by

and

have

the

same

circuit

ID

According

to

serializability

allocFac

operations

conflict

and

this

is

reflected

on

the

conflict

table

of

Fac

objects

Thus

and

can

not

consider

and

allocate

the

same

facilities

i.e.

and

can

not

perform

usedBy

and

allocFac

operations

on

the

same

Fac

object

To

specify

that

and

are

allowed

to

cooperate

we

can

augment

the

conflict

table

of

Fac

objects

to

permit

and

to

allocate

the

same

facility

but

prevent

all

other

transactions

from

doing

the

same

To

represent

transactions

like

T

and

we

introduce

three

corresponding

transaction

types

Complex

transaction

T

has

type

has

type

and

has

type

To

specify

cooperative

transactions

we

augment

the

default

read-write

conflict

table

for

Fac

objects

as

follows

Fac.conflict

table

Fac.conflict

table

-LCB-

Ti

Tj

-LRB-

allocFacj

allocFaci

-RRB-

-LRB-

allocFaci

allocFacj

-RRB-

Ti

Tj?T

type

-LRB-

T

-RRB-

type

-LRB-

Ti

-RRB-

type

-LRB-

Tj

-RRB-

-RCB-

In

this

specification

we

state

that

two

allocFac

operations

do

not

conflict

if

-LRB-

i

-RRB-

they

are

performed

by

a

transaction

of

type

and

one

of

type

and

-LRB-

ii

-RRB-

they

are

constituent

transactions

of

the

same

complex

transaction

of

type

The

specification

of

cooperative

correctness

dependencies

in

this

section

illustrates

that

our

telecommunications-specific

ETM

allows

only

transactions

of

telecommunications-specific

types

-LRB-

i.e.

and

-RRB-

to

cooperate

Thus

our

ETM

specification

framework

can

directly

capture

application

semantics

Specification

of

Temporal

Correctness

Criteria

Cooperative

correctness

criteria

were

proposed

for

ensuring

correctness

in

applications

where

serializability

is

too

restrictive

to

permit

required

functionality

e.g.

allow

multiple

circuit

design

transactions

to

update

the

same

object

repeatedly

While

serializability

is

too

strong

as

a

correctness

criterion

for

applications

that

require

transaction

cooperation

it

is

too

weak

-LRB-

i.e.

may

not

ensure

correctness

-RRB-

in

applications

that

require

a

specific

transaction

execution

order

The

basic

reason

why

serializability

can

not

guarantee

a

specific

transaction

order

is

that

it

considers

all

possible

transaction

orderings

equally

correct

More

specifically

serializability

requires

each

pair

of

conflicting

transactions

to

satisfy

the

following

requirement

the

operations

issued

by

the

one

transaction

should

precede

the

conflicting

operations

issued

by

the

other

transaction

or

vice

versa

To

illustrate

that

this

is

insufficient

to

ensure

a

specific

transaction

execution

order

consider

an

application

that

requires

a

transaction

to

be

executed

after

In

this

case

all

operations

of

must

precede

the

operations

of

Schedules

in

which

an

operation

of

precede

the

operations

of

should

not

be

allowed

In

addition

to

specific

transaction

orders

serializability

and

cooperative

correctness

criteria

do

not

capture

real-time

constraints

such

as

transaction

deadlines

Temporal

correctness

criteria

can

be

specified

in

terms

of

temporal

transaction

dependencies

-LSB-

-RSB-

Such

dependencies

are

constraints

on

the

execution

of

transactions

with

respect

to

time

or

to

an

order

in

time

If

temporal

dependencies

impose

constraints

that

explicitly

refer

to

time

they

are

real-time

dependencies

Temporal

dependencies

of

a

single

transaction

can

only

be

real-time

dependencies

For

example

a

constraint

to

start

the

execution

of

a

transaction

at

time

AM

is

a

real-time

dependency

On

the

other

hand

succession

dependencies

are

temporal

dependencies

that

do

not

impose

real-time

constraints

on

the

execution

of

transactions

They

are

constraints

on

the

ordering

of

transactions

In

this

sense

succession

dependencies

refer

to

time

only

implicitly

Some

issues

related

to

temporal

dependencies

have

been

discussed

in

the

literature

The

synchronization

of

site

clocks

and

ordering

of

events

in

distributed

systems

has

been

addressed

by

Lamport

-LSB-

-RSB-

Deadline

scheduling

has

been

investigated

in

among

others

-LSB-

-RSB-

Elmagarmid

et

al.

-LSB-

-RSB-

and

Ngu

-LSB-

-RSB-

proposed

methods

for

the

specification

of

succession

dependencies

Both

methods

involve

constructing

a

precedence

graph

that

specifies

the

ordering

of

transactions

as

it

is

required

by

the

application

Succession

dependencies

were

also

considered

in

decomposition

of

long-lived

transactions

-LSB-

-RSB-

to

a

collection

of

transactions

with

succession

dependencies

This

was

proposed

because

longlived

transactions

have

a

poor

completion

rate

large

deadlock

probability

and

they

increase

the

number

of

abortions

and

restarts

for

other

transactions

To

deal

with

these

problems

-LSB-

-RSB-

proposed

to

break

long-lived

transactions

into

several

shorter

transactions

with

succession

dependencies

-LRB-

e.g.

sagas

-LSB-

-RSB-

or

activities

of

causally

dependent

detached

transactions

-LSB-

-RSB-

-RRB-

Most

of

the

methods

above

had

limitations

in

capturing

temporal

transaction

dependencies

including

-LRB-

i

-RRB-

they

required

that

all

transactions

having

temporal

dependencies

must

be

known

in

advance

and

-LRB-

ii

-RRB-

they

did

not

consider

or

capture

concurrent

execution

of

transactions

that

have

temporal

dependencies

These

problems

were

addressed

in

-LSB-

-RSB-

Next

we

discuss

succession

dependencies

and

their

specification

A

discussion

on

the

specification

of

real-time

dependencies

follows

Succession

dependencies

and

their

specification

Transactions

that

have

succession

dependencies

may

or

may

not

access

common

objects

For

example

consider

a

situation

in

which

a

travel

agent

submits

two

transactions

-LRB-

possibly

to

different

reservation

systems

-RRB-

to

make

flight

and

hotel

reservations

for

the

future

travel

of

a

customer

Such

transactions

have

no

conflicts

according

to

serializability

However

a

succession

dependency

exists

between

them

as

the

hotel

reservation

is

useless

if

the

flight

reservation

is

not

made

Usually

dependent

transactions

in

this

category

carry

out

successive

steps

that

accomplish

a

single

activity

-LRB-

e.g.

a

business

process

workflow

-RRB-

that

for

various

reasons

can

not

be

executed

as

a

single

transaction

Succession

dependencies

ensure

correctness

by

preventing

out-of-order

execution

of

these

steps

A

succession

dependency

between

two

transactions

that

issue

conflicting

operations

exists

if

one

of

the

transactions

needs

to

use

the

results

of

the

other

transaction

to

produce

correct

results

For

example

transactions

in

a

telecommunication

application

that

set

a

new

service

rate

compute

service

fees

for

each

customer

and

record

service

charges

to

the

customer

accounts

in

a

billing

database

must

be

executed

in

this

order

to

accomplish

their

objectives

correctly

The

succession

dependencies

in

each

particular

application

are

defined

by

application

semantics

If

a

succession

dependency

between

transactions

is

not

satisfied

dependent

transactions

may

produce

invalid

results

in

the

same

way

the

violation

of

serializability

can

produce

inconsistent

retrievals

e.g.

an

invalid

service

rate

may

be

used

to

compute

and

display

the

service

fee

for

a

customer

account

Furthermore

it

is

also

possible

that

the

violation

of

a

succession

dependency

may

introduce

inconsistent

updates

e.g.

the

charges

recorded

in

a

customer

account

database

may

be

based

on

an

invalid

service

rate

Assuming

that

serial

-LRB-

non-interleaved

-RRB-

transaction

execution

is

acceptable

succession

dependencies

can

be

specified

as

transaction

state

dependencies

For

example

consider

the

succession

dependency

SD

among

a

transaction

that

sets

a

new

service

rate

and

a

transaction

that

computes

service

fees

for

a

customer

SD

is

satisfied

if

commits

before

begins

Therefore

SD

can

be

specified

by

the

state

dependency

can

not

begin

before

commits

In

many

cases

transactions

having

succession

dependencies

can

be

executed

concurrently

For

example

the

transactions

to

perform

flight

and

hotel

reservations

for

a

trip

can

be

interleaved

The

only

restriction

is

that

the

hotel

reservation

transaction

should

be

committed

after

-LRB-

and

only

if

-RRB-

the

flight

reservation

transaction

is

successfully

committed

Similarly

in

our

telecommunications

example

the

transaction

that

computes

and

records

the

service

fees

can

be

interleaved

with

the

transaction

that

sets

a

new

service

rate

To

guarantee

correctness

in

this

case

we

only

need

to

ensure

that

sees

the

new

service

rate

produced

by

Succession

dependencies

between

concurrent

transactions

that

do

not

access

the

same

objects

can

be

specified

by

transaction

state

dependencies

For

example

the

succession

dependency

in

our

travel

reservation

scenario

can

be

specified

by

the

state

dependency

can

not

commit

before

commits

On

the

other

hand

state

dependencies

can

not

capture

succession

dependencies

between

concurrent

transactions

that

perform

conflicting

operations

For

example

the

state

dependency

can

not

commit

before

commits

does

not

capture

the

requirement

that

the

transaction

that

computes

the

usage

fees

must

use

the

new

service

rate

produced

by

i.e.

may

read

the

old

rate

before

it

is

set

by

A

framework

to

analyze

the

concurrent

execution

of

transactions

with

succession

dependencies

has

been

formulated

in

-LSB-

-RSB-

Since

concurrent

transaction

execution

may

be

required

-LRB-

e.g.

to

improve

throughput

and/or

allow

necessary

functionality

-RRB-

we

use

this

framework

to

analyze

succession

dependencies

and

derive

corresponding

descriptors

as

described

next

Let

SD

be

a

succession

dependency

between

transactions

Tk

in

a

schedule

H.

To

represent

SD

we

use

the

following

notation

SD

t

t.

t

Tk

SD

defines

a

temporal

precedence

-LRB-

TM-precedence

-RRB-

relation

t

between

transactions

Tk

In

particular

a

transaction

TM-precedes

transaction

Ti

in

SD

-LRB-

tTi

i

k

-RRB-

if

performs

its

write

operations

earlier

in

time

than

Ti

-LRB-

even

if

writes

are

on

different

objects

-RRB-

Furthermore

if

Ti

reads

objects

which

writes

precedes

Ti

only

if

Ti

reads

all

such

objects

after

writes

them

A

schedule

H

satisfies

SD

if

it

preserves

the

TM-precedence

relation

among

Tk

A

schedule

H

that

satisfies

SD

is

called

a

succession

with

respect

to

SD

Like

serializability

-LSB-

-RSB-

the

definition

of

a

temporal

correctness

criterion

that

captures

concurrent

successions

involves

defining

-LSB-

-RSB-

-LRB-

i

-RRB-

schedules

that

are

known

to

be

correct

i.e.

satisfy

SD

and

-LRB-

ii

-RRB-

conditions

under

which

schedules

are

equivalent

Unlike

serializability

theory

all

serial

schedules

do

not

satisfy

SD

i.e.

are

not

successions

with

respect

to

SD

Furthermore

there

exist

concurrent

schedules

that

are

conflictc

equivalent

-LSB-

-RSB-

with

a

schedule

that

satisfies

SD

but

they

do

not

themselves

preserve

SD

Differences

between

serializability

and

the

theory

of

succession

dependencies

are

discussed

further

in

-LSB-

-RSB-

To

specify

a

succession

dependency

SD

t.

tTk

between

-LRB-

possibly

concurrent

-RRB-

transactions

we

first

define

the

TM-precedence

relation

between

the

transactions

in

t

-LCB-

T

k

-RCB-

assuming

that

H

is

a

schedule

over

t

and

a

set

of

objects

O.

Next

we

use

the

TM-precedence

relation

defined

by

SD

to

derive

dependency

descriptors

for

successions

with

respect

to

SD

A

transaction

Ti

directly

TM-precedes

Tj

in

H

-LRB-

denoted

by

Ti

TM

-LRB-

t

O

-RRB-

T

j

-RRB-

iff

Ti

directly

SR-precedes

Tj

in

H

In

addition

Ti

directly

TM-precedes

Tj

iff

-LRB-

i

-RRB-

Ti

performs

a

write

operation

that

precedes

any

write

operation

of

Tj

in

H

and

-LRB-

ii

-RRB-

Ti

and

Tj

are

non-aborted

transactions

Indirect

TM-precedence

between

Ti

and

Tj

is

defined

as

indirect

SR-precedence

in

Section

Thus

the

transitive

closure

Ti

TM

-LRB-

t

O

-RRB-

Tj

of

the

TM-precedence

relation

determines

whether

Ti

TM-precedes

directly

or

indirectly

Tj

in

H

i.e.

n?N?Ti

TMn

-LRB-

t

O

-RRB-

Tj

where

N

is

the

set

of

positive

integers

Let

tc

be

the

set

of

all

committed

transactions

in

H.

H

is

a

succession

with

respect

to

SD

iff

for

every

pair

of

transactions

Ti

and

Tj

in

tc

such

that

Tj

tTi

in

SD

Ti

does

not

TM

precede

T

j

or

itself

Tj

tTi

SD

Ti

tc

Tj

tc

-LSB-

Ti

TM

-LRB-

tc

O

-RRB-

Tj

Ti

TM

-LRB-

tc

O

-RRB-

Ti

-RSB-

In

the

specification

above

-LSB-

Ti

TM

-LRB-

tc

O

-RRB-

Tj

-RSB-

is

needed

to

ensure

that

Ti

does

not

temporally

precede

Tj

-LRB-

Ti

TM

-LRB-

tc

O

-RRB-

Tj

clearly

violates

Tj

tTi

-RRB-

The

second

postcondition

component

-LSB-

Ti

TM

-LRB-

tc

O

-RRB-

Ti

-RSB-

ensures

that

Ti

does

not

issue

operations

that

form

cycles

c

As

defined

by

serializability

theory

-LSB-

-RSB-

Ti

TM

-LRB-

t

O

-RRB-

Tj

true

false

otherwise

Ti

SR

-LRB-

t

O

-RRB-

Tj

-LSB-

pi

-LRB-

ox

-RRB-

Ti

qj

-LRB-

oy

-RRB-

Tj

Ti

Tj?t

i

j

ox

oy

O

-LRB-

pi

-LRB-

ox

-RRB-

w

-RRB-

-LRB-

qj

-LRB-

oy

-RRB-

w

-RRB-

-LRB-

pi

-LRB-

ox

-RRB-

qj

-LRB-

oy

-RRB-

-RRB-

-LRB-

aborti

abortj

H

-RRB-

-RSB-

Ti

TMn

-LRB-

t

O

-RRB-

Tj

true

false

otherwise

Ti

-LRB-

t

O

-RRB-

Tj

-LSB-

Tk?T

Ti

-LRB-

t

O

-RRB-

Tk

Tk

-LRB-

t

O

-RRB-

Tj

-RSB-

n

This

is

required

to

ensure

that

the

temporal

order

of

Ti

is

unique

For

a

similar

reason

-LSB-

Ti

SR

-LRB-

tc

O

-RRB-

Ti

-RSB-

is

needed

to

preserve

serializability

The

following

succession

dependency

descriptors

state

that

a

schedule

H

satisfies

SD

-LRB-

i.e.

H

is

a

succession

with

respect

to

SD

-RRB-

Tj

tTi

SD

-LRB-

Ti

tc-Ti

O

-LSB-

Ti.state

Commit

-RSB-

-LSB-

Tj.state

Commit

-RSB-

-LSB-

Ti

TM

-LRB-

tc

O

-RRB-

Tj

Ti

TM

-LRB-

tc

O

-RRB-

Ti

-RSB-

-RRB-

If

any

of

the

dependency

descriptors

above

is

violated

the

succession

dependency

SD

is

also

violated

To

ensure

SD

all

transactions

must

have

dependency

descriptors

similar

to

those

above

and

all

such

dependencies

must

be

satisfied

Real-time

dependencies

and

their

specification

Earlier

we

defined

real-time

dependencies

as

the

category

of

temporal

dependencies

that

impose

constraints

that

explicitly

refer

to

time

Real-time

dependencies

are

typically

real-time

transaction

state

dependencies

For

example

consider

again

the

transactions

to

set

a

new

service

rate

and

compute

the

usage

fees

for

each

customer

account

One

way

to

preserve

consistency

is

to

ensure

that

the

transaction

that

sets

a

new

service

rate

finishes

its

execution

at

time

the

transaction

that

computes

the

service

charges

begins

at

time

and

is

later

than

This

can

be

enforced

by

specifying

the

following

strong

real-time

dependencies

on

the

commit

and

begin

states

of

transactions

and

respectively

-LRB-

-LCB-

-RCB-

-LCB-

-RCB-

-LCB-

-RCB-

-LRB-

-RRB-

Commit

-LRB-

-RRB-

-RRB-

-LRB-

-LCB-

-RCB-

-LCB-

-RCB-

-LCB-

-RCB-

-LRB-

-RRB-

Begin

-LRB-

-RRB-

-RRB-

Since

and

do

not

depend

on

other

transactions

or

objects

the

transaction

set

and

the

object

set

-LRB-

elements

t

and

O

-RRB-

in

the

dependency

descriptors

above

are

empty

On

the

other

hand

the

time

vector

-LRB-

originally

defined

by

t

in

Section

-RRB-

contains

the

time

each

transaction

depends

on

In

all

other

dependency

descriptors

we

have

defined

until

now

the

time

vector

was

empty

and

was

not

included

Backward

and

forward

real-time

dependencies

can

be

defined

similarly

Specification

and

enforcement

of

real-time

dependencies

on

transaction

states

other

than

the

commit

state

are

straightforward

and

we

do

not

discuss

them

further

If

strong

real-time

dependencies

on

the

commit

state

of

transactions

define

real-time

deadlines

they

may

not

always

be

easy

to

enforce

For

example

while

it

is

relatively

easy

to

ensure

that

transactions

with

strong

real-time

dependencies

on

their

begin

state

such

as

are

started

on

time

there

are

serious

theoretical

and

practical

problems

to

overcome

to

ensure

that

transactions

with

strong

real-time

dependencies

on

their

commit

state

such

as

meet

their

real-time

deadlines

Deadline

scheduling

problems

have

been

investigated

in

-LSB-

-RSB-

and

we

do

not

address

them

here

Specification

of

Visibility

Dependencies

Correctness

criteria

such

as

serializability

are

sufficient

to

ensure

the

correctness

of

concurrent

transaction

executions

only

in

the

absence

of

failures

To

ensure

correctness

in

the

presence

of

failures

schedules

must

also

be

recoverable

-LRB-

RC

-RRB-

-LSB-

-RSB-

However

in

reality

transaction

processing

systems

often

enforce

stronger

-LRB-

i.e.

more

restrictive

-RRB-

visibility

constraints

that

in

addition

to

ensuring

recoverability

reduce

overhead

and

simplify

recovery

-LSB-

-RSB-

There

are

three

basic

visibility

criteria

that

have

been

proposed

in

the

literature

cascadelessness

-LRB-

CS

-RRB-

strictness

-LRB-

ST

-RRB-

and

rigorousness

-LRB-

RG

-RRB-

Schedules

that

satisfy

them

have

the

following

properties

A

schedule

is

cascadeless

-LSB-

-RSB-

if

no

object

is

read

until

the

transactions

that

previously

wrote

it

commit

or

abort

i.e.

it

disallows

write-read

conflicts

between

uncommitted

transactions

A

schedule

is

strict

-LSB-

-RSB-

if

it

is

cascadeless

and

no

object

is

written

until

the

transactions

that

previously

wrote

it

commit

or

abort

i.e.

it

disallows

both

write-write

and

write-read

conflicts

between

uncommitted

transactions

A

schedule

is

rigorous

-LSB-

-RSB-

if

it

is

strict

and

no

object

is

written

until

the

transactions

that

previously

read

it

either

commit

or

abort

i.e.

it

disallows

all

conflicts

between

uncommitted

transactions

RC

CS

ST

and

RG

are

increasingly

restrictive

properties

i.e.

strict

schedules

cascadeless

schedules

recoverable

schedules

-LSB-

-RSB-

and

rigorous

schedules

strict

schedules

-LSB-

-RSB-

CS

simplifies

recovery

because

it

avoids

cascading

aborts

-LRB-

i.e.

situations

in

which

a

transaction

Ti

reads

an

object

previously

written

by

an

uncommitted

transaction

Tj

and

then

Tj

aborts

forcing

Ti

also

to

abort

-RRB-

ST

is

required

to

allow

the

use

of

before

images

for

efficient

recovery

-LSB-

-RSB-

RG

has

these

properties

and

in

addition

ensures

serializability

i.e.

rigorous

schedules

serializable

schedules

-LSB-

-RSB-

The

relationship

of

schedules

allowed

by

the

visibility

criteria

discussed

above

is

illustrated

in

Figure

Assuming

that

H

is

a

schedule

over

a

set

of

transactions

t

-LCB-

Tk

-RCB-

and

a

set

of

objects

O

write-read

write-write

and

read-write

conflicts

define

the

following

read-from

-LRB-

RF

-RRB-

update-overwrite

-LRB-

UO

-RRB-

and

retrieval-overwrite

-LRB-

RO

-RRB-

precedence

relations

that

are

essential

in

specifying

CS

ST

and

RG

serializable

schedules

cascadeless

schedules

strict

schedules

rigorous

schedules

recoverable

schedules

Figure

Relationships

of

schedules

allowed

by

different

visibility

criteria

A

transaction

Ti

directly

RF-precedes

Tj

in

H

-LRB-

denoted

by

Ti

RF

-LRB-

t

O

-RRB-

Tj

-RRB-

iff

Ti

and

Tj

have

a

write-read

conflict

that

occurs

while

both

transactions

are

uncommitted

A

transaction

Ti

directly

UO-precedes

Tj

in

H

-LRB-

denoted

by

Ti

UO

-LRB-

t

O

-RRB-

Tj

-RRB-

iff

Ti

and

Tj

have

a

write-write

conflict

that

occurs

while

both

transactions

are

uncommitted

A

transaction

Ti

directly

RO-precedes

Tj

in

H

-LRB-

denoted

by

Ti

RO

-LRB-

t

O

-RRB-

Tj

-RRB-

iff

Ti

and

Tj

have

a

read-write

conflict

that

occurs

while

both

transactions

are

uncommitted

For

example

in

the

schedule

-LRB-

oy

-RRB-

-LRB-

oy

-RRB-

-LRB-

oz

-RRB-

-LRB-

oz

-RRB-

-LRB-

oz

-RRB-

-LRB-

t

O

-RRB-

holds

because

of

the

operations

-LRB-

oz

-RRB-

and

-LRB-

oz

-RRB-

Having

defined

the

direct

visibility

precedence

relations

RF

UO

and

RO

defining

the

dependency

descriptors

for

CS

ST

and

RG

is

straightforward

A

schedule

H

is

CS

if

every

transaction

in

t

has

the

following

cascadeless

dependencies

A

schedule

H

is

ST

if

every

transaction

in

t

has

the

following

strictness

dependencies

A

schedule

H

is

RG

if

every

transaction

in

t

has

the

following

rigorous

dependencies

Ti

RF

-LRB-

t

O

-RRB-

Tj

true

false

otherwise

pi

-LRB-

ox

-RRB-

Ti

qj

-LRB-

ox

-RRB-

Tj

Ti

Tj?t

i

j

ox?O

-LSB-

-LRB-

pi

-LRB-

ox

-RRB-

qj

-LRB-

ox

-RRB-

-RRB-

ox.conflict

table

-RSB-

-LSB-

pi

-LRB-

ox

-RRB-

qj

-LRB-

ox

-RRB-

-RSB-

-LSB-

pi

-LRB-

o

x

-RRB-

w

-RSB-

-LSB-

qj

-LRB-

ox

-RRB-

r

-RSB-

-LSB-

aborti

abortj

H

-RSB-

-LSB-

-LRB-

commiti

qj

-LRB-

ox

-RRB-

-RRB-

-RSB-

Ti

UO

-LRB-

t

O

-RRB-

Tj

true

false

otherwise

pi

-LRB-

ox

-RRB-

Ti

qj

-LRB-

ox

-RRB-

Tj

Ti

Tj?t

i

j

ox?O

-LSB-

-LRB-

pi

-LRB-

ox

-RRB-

qj

-LRB-

o

x

-RRB-

-RRB-

ox.conflict

lable

-RSB-

-LSB-

pi

-LRB-

ox

-RRB-

qj

-LRB-

ox

-RRB-

-RSB-

-LSB-

pi

-LRB-

ox

-RRB-

w

-RSB-

-LSB-

qj

-LRB-

ox

-RRB-

w

-RSB-

-LSB-

aborti

abortj

H

-RSB-

-LSB-

-LRB-

commiti

qj

-LRB-

ox

-RRB-

-RRB-

-RSB-

Ti

RO

-LRB-

t

O

-RRB-

Tj

true

false

otherwise

pi

-LRB-

ox

-RRB-

Ti

qj

-LRB-

ox

-RRB-

Tj

Ti

Tj?t

i

j

ox?O

-LSB-

-LRB-

pi

-LRB-

ox

-RRB-

qj

-LRB-

ox

-RRB-

-RRB-

ox.conflict

lable

-RSB-

-LSB-

pi

-LRB-

ox

-RRB-

qj

-LRB-

ox

-RRB-

-RSB-

-LSB-

pi

-LRB-

ox

-RRB-

r

-RSB-

-LSB-

qj

-LRB-

ox

-RRB-

w

-RSB-

-LSB-

aborti

abortj

H

-RSB-

-LSB-

-LRB-

commiti

qj

-LRB-

ox

-RRB-

-RRB-

-RSB-

Tj

t-Ti

Ti

t

-LRB-

Ti

t-Ti

O

true

-LSB-

Tj

RF

-LRB-

t

O

-RRB-

Ti

-RSB-

-RRB-

Tj

t-Ti

Ti

t

-LRB-

Ti

t-Ti

O

true

-LSB-

Tj

RF

-LRB-

t

O

-RRB-

Ti

Tj

UO

-LRB-

t

O

-RRB-

Ti

-RSB-

-RRB-

Tj

t-Ti

Ti

t

-LRB-

Ti

t-Ti

O

true

-LSB-

Tj

RF

-LRB-

t

O

-RRB-

Ti

Tj

UO

-LRB-

t

O

-RRB-

Ti

Tj

RO

-LRB-

t

O

-RRB-

Ti

-RSB-

-RRB-

The

definitions

above

of

CS

ST

and

RG

take

into

account

operation

semantics

In

particular

unlike

the

original

definitions

of

CS

ST

and

RG

in

-LSB-

-RSB-

the

visibility

precedence

relations

RF

UO

and

RO

test

if

operations

conflict

semantically

in

addition

to

whether

they

are

reads

or

writes

For

example

consider

two

insert

operations

-LRB-

S

-RRB-

and

-LRB-

S

-RRB-

that

are

issued

by

uncommitted

transactions

and

on

a

set

object

S.

Assuming

that

the

conflict

table

of

S

takes

into

account

operation

semantics

-LRB-

S

-RRB-

does

not

conflict

with

-LRB-

S

-RRB-

i.e.

-LRB-

-LRB-

S

-RRB-

-LRB-

S

-RRB-

-RRB-

S.conflict

table

In

this

case

of

the

visibility

precedence

relations

above

hold

On

the

other

hand

if

S

uses

the

default

read-write

conflict

table

the

-LRB-

S

-RRB-

and

-LRB-

S

-RRB-

operations

constitute

a

write-write

conflict

between

and

and

-LRB-

t

-LCB-

S

-RCB-

-RRB-

holds

Note

that

indirect

visibility

precedence

relations

can

be

defined

similarly

to

indirect

SR-precedence

in

Section

However

since

indirect

visibility

precedence

does

not

seem

to

be

more

useful

in

the

specification

of

ETMs

than

direct

precedence

we

do

not

discuss

it

further

Other

visibility

criteria

including

strong-recoverability

and

semi-rigorouseness

have

been

discussed

in

-LSB-

-RSB-

Their

specifications

are

similar

to

those

of

CS

ST

and

RG

Related

Work

An

automata-based

specification

of

state

dependencies

is

discussed

in

-LSB-

-RSB-

This

approach

can

not

be

used

to

specify

correctness

criteria

The

problem

is

that

automata

can

capture

only

regular

languages

Specification

of

arbitrary

execution

schedules

allowed

by

various

correctness

criteria

requires

a

context

free

or

a

context

sensitive

language

Therefore

the

automata-based

specification

approach

is

not

sufficiently

powerful

to

specify

many

ETMs

Like

our

framework

ACTA

-LSB-

-RSB-

supports

ETM

specification

and

implementationindependent

reasoning

about

transaction-execution

correctness

and

structure

The

main

difference

between

dependency

specifications

and

ACTA

is

that

our

dependency

descriptors

provide

reliable

true

and

false

evaluation

results

This

is

necessary

if

ETM

specifications

must

be

enforced

by

a

software

system

-LRB-

e.g

as

DBMSs

enforce

ACID

transactions

-RRB-

In

particular

if

the

result

of

a

dependency

specification

evaluation

is

true

this

must

imply

that

the

dependency

is

ensured

On

the

other

hand

a

false

result

should

indicate

a

failure

in

ensuring

ETM

specifications

This

kind

of

reasoning

is

not

supported

by

ACTA

The

problem

is

that

it

is

not

always

possible

to

determine

whether

a

dependency

is

satisfied

or

not

simply

because

the

available

execution

schedule

does

not

provide

enough

information

For

example

consider

the

dependency

can

not

begin

before

commits

where

depends

on

Until

begins

there

is

not

enough

information

in

the

schedule

to

determine

whether

dependency

is

satisfied

As

we

discussed

in

Section

dependency

descriptors

deal

with

this

problem

by

having

an

enabling

condition

that

prevents

dependency

descriptor

evaluation

until

there

is

enough

information

available

For

example

suppose

that

the

enabling

condition

En

in

dependency

descriptor

is

set

to

Begin

While

En

is

false

the

dependency

specification

evaluates

to

don?t

know

ACTA

does

not

support

enabling

conditions

and

does

not

allow

don?t

know

evaluation

results

Due

to

the

lack

of

these

ACTA

specifications

may

result

in

false

evaluations

becoming

true

when

there

is

enough

information

in

the

schedule

and

vice

versa

For

example

if

the

ACTA

specification

of

the

dependency

can

not

begin

before

commits

is

evaluated

before

begins

the

result

is

false

This

may

change

when

issues

Begin

In

particular

if

has

performed

Commit

when

issues

Begin

the

evaluation

result

of

the

ACTA

specification

changes

to

true

Such

unreliable

evaluation

makes

ACTA

specifications

difficult

to

use

To

deal

with

this

problem

ACTA

originally

required

the

availability

of

a

finite

execution

schedule

-LSB-

-RSB-

i.e.

a

schedule

that

contains

all

transactional

events

-LRB-

e.g.

Begin

Commit

Abort

-RRB-

pertaining

to

all

transactions

under

consideration

To

capture

executions

in

progress

the

finite

schedule

requirement

has

been

relaxed

in

recent

revisions

of

ACTA

However

the

unreliable

evaluation

problem

still

remains

Providing

reliable

true

and

false

evaluation

results

as

provided

by

our

approach

allows

determining

specification

violations

as

soon

as

dependencies

are

enabled

purging

descriptors

of

satisfied

state

dependencies

as

soon

as

they

are

enabled

and

evaluated

evaluating

dependency

descriptors

before

the

finite

execution

schedule

is

available

using

dependency

descriptors

to

enforce

ETMs

In

principle

enforcing

ETMs

can

be

done

by

-LRB-

i

-RRB-

evaluating

specifications

-LRB-

i.e.

the

dependency

descriptors

corresponding

to

an

ETM

-RRB-

when

transactions

issue

new

operations

and

-LRB-

ii

-RRB-

synchronizing

transaction

execution

according

to

evaluation

results

-LRB-

i.e.

permit

the

execution

of

operations

only

if

they

do

not

result

in

a

false

evaluation

result

-RRB-

However

the

performance

of

such

an

enforcement

mechanism

may

be

unacceptable

for

most

applications

In

practice

conventional

transaction

management

technology

-LRB-

e.g.

transaction

schedulers

rules

-RRB-

should

be

used

to

enforce

dependency

specifications

In

-LSB-

-RSB-

we

described

a

Transaction

Specification

and

Management

Environment

-LRB-

TSME

-RRB-

that

supports

the

definition

and

enforcement

of

application-specific

ETMs

The

TSME

allows

ETM

specification

by

dependency

descriptors

The

TSME

supports

ETM

enforcement

by

a

transaction

management

mechanism

toolkit

which

provides

rules

for

enforcing

transaction

state

dependencies

and

a

programmable

scheduler

for

ensuring

correctness

dependencies

To

configure

a

transaction

management

mechanism

that

enforces

a

specified

ETM

the

TSME

uses

ETM

specifications

to

produce

instructions

for

the

transaction

management

toolkit

The

TSME

is

discussed

further

in

-LSB-

-RSB-

Another

important

difference

between

our

transaction

specification

framework

and

ACTA

is

that

our

framework

requires

only

standard

quantifiers

on

finite

transaction

sets

and

a

single

operator

-LRB-

transitive

closure

-RRB-

Furthermore

ACTA

allows

only

conflict

tables

defined

according

to

commutativity

Our

conflict

tables

may

be

defined

using

any

conflict

definition

that

may

be

provided

by

an

application

used

by

a

legacy

system

or

specified

by

an

object

designer

Finally

our

framework

directly

captures

application

semantics

that

other

transaction

specification

frameworks

do

not

For

example

-LSB-

-RSB-

discusses

merging

two

existing

ETMs

to

create

a

new

nested/split

ETM

which

allows

cooperation

between

subtransactions

of

nested

transactions

The

telecommunications-specific

ETM

specified

in

this

paper

also

allows

constituent

transactions

of

extended

transactions

to

cooperate

-LRB-

Section

-RRB-

A

basic

different

between

the

nested/split

transaction

model

-LRB-

section

in

-LSB-

-RSB-

-RRB-

and

our

telecommunications-specific

ETM

is

that

the

latter

allows

only

transactions

of

telecommunications-specific

types

-LRB-

i.e.

and

PROV

-RRB-

to

cooperate

The

nested/split

transaction

model

-LSB-

-RSB-

does

not

capture

such

a

requirement

Summary

and

Conclusion

A

transaction

specification

framework

is

needed

in

a

distributed

environment

consisting

of

autonomous

and

heterogeneous

systems

for

allowing

ETM

designers

to

reason

about

the

correctness

of

transactions

independently

of

their

implementation

providing

existing

ETMs

-LRB-

proven

to

support

specific

applications

-RRB-

as

templates

which

can

be

tailored

to

reflect

application

requirements

and

evolve

as

application

requirements

evolve

developing

new

ETMs

from

existing

ones

by

composing

their

dependency

descriptors

comparing

transaction

specifications

with

the

correctness

guarantees

provided

by

participating

systems

to

determine

whether

specifications

can

be

enforced

Our

ETM

specification

framework

provides

sufficient

specification

power

to

support

these

objectives

We

have

used

the

framework

described

in

this

paper

for

the

specification

of

several

ETMs

including

nested

transactions

-LSB-

-RSB-

sagas

-LSB-

-RSB-

variations

of

closed

and

open

nested

transactions

-LSB-

-RSB-

multitransactions

-LSB-

-RSB-

and

flexible

transactions

-LSB-

-RSB-

Detailed

specifications

are

provided

in

-LSB-

-RSB-

In

addition

we

have

used

dependency

descriptors

for

designing

new

application-specific

ETMs

for

various

telecommunication

applications

Beyond

specification

power

our

dependency

descriptors

are

enforceable

i.e.

they

can

be

evaluated

at

any

time

during

transaction

execution

to

determine

whether

issued

operations

violated

the

specifications

of

an

ETM

The

feasibility

of

software

systems

that

enforce

ETM

specifications

has

been

illustrated

in

-LSB-

-RSB-

Transaction

management

performance

becomes

an

issue

when

a

software

system

is

used

to

enforce

ETM

specifications

The

following

factors

determine

transaction

management

performance

application

functionality

requirements

corresponding

to

ETM

complexity

and

the

transaction

management

mechanism

used

to

enforce

a

specified

ETM

For

example

if

a

specified

ETM

is

a

combination

of

ACID

nested

and/or

chained

transactions

transaction

management

performance

could

be

identical

to

that

of

DBMSs

that

support

these

kinds

of

transactions

-LRB-

since

the

same

transaction

management

mechanism

technology

can

be

used

-RRB-

On

the

other

hand

if

an

ETM

takes

into

account

transaction

semantics

and

allows

transaction

cooperation

a

scheduler

that

supports

breakpoints

can

be

developed

-LRB-

e.g.

as

described

in

-LSB-

-RSB-

-RRB-

and

benchmarked

to

determine

whether

its

performance

meets

application

requirements

If

transaction

management

performance

does

not

satisfy

application

requirements

the

application

requirements

can

be

re-examined

the

ETM

can

be

re-designed

accordingly

and

the

transaction

scheduler

can

be

tuned

or

modified

until

performance

objectives

are

met

Thus

although

transaction

management

performance

does

not

depend

on

the

ETM

specification

framework

our

ETM

specification

framework

can

support

ETM

re-design

for

meeting

application

throughput

and

functionality

requirements

References

R.

Abbott

and

H.

Garcia-Molina

Scheduling

Real-Time

Transactions

A

Performance

Evaluation

Proceedings

of

the

International

Conference

on

VLDB

P.

Attie

M.

Singh

A.

Sheth

M.

Rusinkiewicz

Specifying

and

Enforcing

Intertask

Dependencies

Proceedings

of

the

International

Conference

on

VLDB

August

Y.

Breitbart

D.

Georgakopoulos

M.

Rusinkiewicz

and

A.

Silberschatz

On

Rigorous

Transaction

Scheduling

IEEE

Trans

on

Software

Engineering

-LRB-

-RRB-

September

P.A.

Bernstein

V.

Hadzilacos

and

N.

Goodman

Concurrency

Control

and

Recovery

in

Database

Systems

Addison-Wesley

A.

Buchmann

M.

Ozsu

M.

Hornick

D.

Georgakopoulos

F.

Manola

A

Transaction

Model

for

Active

Distributed

Object

Systems

Advanced

Transaction

Models

for

New

Applications

A.

Elmagarmid

-LRB-

ed

-RRB-

Morgan-Kaufmann

B.

Badrinath

and

K.

Ramamritham

Semantics-based

Concurrency

Control

Beyond

Commutativity

Proceedings

of

International

Conference

on

Data

Engineering

P.

Bernstein

J.

Rothnie

N.

Goodman

and

C.

Papadimitriou

The

Concurrency

Control

Mechanism

of

A

System

for

Distributed

Databases

-LRB-

The

Fully

Redundant

Case

-RRB-

IEEE

Trans

on

Software

Engineering

-LRB-

-RRB-

May

P.

Chrysanthis

and

K.

Ramamritham

ACTA

A

Framework

for

Specifying

and

Reasoning

About

Transaction

Structure

and

Behavior

Proceedings

of

the

ACM

SIGMOD

Conference

of

Management

of

Data

P.

Chrysanthis

and

K.

Ramamritham

ACTA

The

SAGA

Continues

Advanced

Transaction

Models

for

New

Applications

A.

Elmagarmid

-LRB-

ed

-RRB-

Morgan-Kaufmann

W.

Du

and

A.

Elmagarmid

QSR

A

Correctness

Criterion

for

Global

Concurrency

Control

in

InterBase

Proceedings

of

the

International

Conference

on

VLDB

U.

Dayal

M.

Hsu

and

R.

Ladin

Organizing

Long-Running

Activities

with

Triggers

and

Transactions

Proceedings

of

the

ACM

SIGMOD

Conference

on

Management

of

Data

U.

Dayal

M.

Hsu

and

R.

Ladin

A

Transactional

Model

for

Long-Running

Activities

Proceedings

of

the

International

Conference

on

VLDB

A.

Elmagarmid

Y.

Leu

W.

Litwin

and

M.

Rusinkiewicz

A

Multidatabase

Transaction

Model

for

InterBase

Proceedings

of

the

International

Conference

on

VLDB

Advanced

Transaction

Models

for

New

Applications

A.

Elmagarmid

-LRB-

ed

-RRB-

Morgan-Kaufmann

A.

Farrag

and

T.

Ozsu

Using

Semantic

Knowledge

of

Transactions

to

Increase

Concurrency

ACM

Trans

on

Database

Systems

-LRB-

-RRB-

December

D.

Georgakopoulos

and

M.

Hornick

An

Environment

for

the

Specification

and

Management

of

Extended

Transactions

and

Workflows

in

DOMS

Tech

Report

GTE

Laboratories

Incorporated

Oct.

D.

Georgakopoulos

et

al.

An

Extended

Transaction

Environment

for

Workflows

in

Distributed

Object

Computing

Data

Engineering

-LRB-

-RRB-

June

D.

Georgakopoulos

M.

Hornick

Piotr

Krychniak

and

Frank

Manola

Specification

and

Management

of

Extended

Transactions

in

a

Programmable

Transaction

Environment

Proceedings

of

the

Int

Conf

on

Data

Engineering

Houston

TX

February

H.

Garcia-Molina

Using

Semantic

Knowledge

for

Transaction

Processing

in

a

Distributed

Database

ACM

Trans

on

Database

Systems

-LRB-

-RRB-

June

D.

Georgakopoulos

M.

Rusinkiewicz

and

W.

Litwin

Chronological

Scheduling

of

Transactions

with

Temporal

Dependencies

VLDB

Journal

January

D.

Georgakopoulos

M.

Rusinkiewicz

and

A.

Sheth

On

Serializability

of

Multidatabase

Transactions

Through

Forced

Local

Conflicts

Proceedings

of

the

Int

Conf

on

Data

Engineering

D.

Georgakopoulos

M.

Rusinkiewicz

and

A.

Sheth

Using

Ticket-based

Methods

to

Enforce

the

Serializability

of

Multidatabase

Transactions

IEEE

Trans

on

Data

and

Knowledge

Engineering

February

H.

Garcia-Molina

and

K.

Salem

SAGAS

Proceedings

of

ACM

SIGMOD

Conf

on

Management

of

Data

M.

Herlihy

Apologizing

Versus

Asking

Permission

Optimistic

Concurrency

Control

for

Abstract

Data

Types

ACM

Trans

on

Database

Systems

-LRB-

-RRB-

Special

Issue

on

Workflow

and

Extended

Transaction

Systems

Data

Engineering

M.

Hsu

-LRB-

ed

-RRB-

-LRB-

-RRB-

June

L.

Lamport

Time

Clocks

and

the

Ordering

of

Events

in

a

Distributed

System

Communications

of

ACM

-LRB-

-RRB-

July

N.

Lynch

Multilevel

atomicity

A

New

Correctness

Criterion

for

Database

Concurrency

Control

ACM

Trans

on

Database

Systems

-LRB-

-RRB-

December

F.

Manola

S.

Heiler

D.

Georgakopoulos

M.

Hornick

and

M.

Brodie

Distributed

Object

Management

Int

Journal

of

Intelligent

and

Cooperative

Inf

Systems

-LRB-

-RRB-

March

E.

Moss

Nested

Transactions

Cambridge

MA

MIT

Press

A.

H.

H.

Ngu

Specification

and

Verification

of

Temporal

Relationships

in

Transaction

Modeling

Information

Systems

-LRB-

-RRB-

K.

Ramamritham

and

P.

Chrysanthis

In

Search

of

Acceptability

Criteria

Database

Consistency

Requirements

and

Transaction

Correctness

Properties

Proceedings

of

the

Internal

Workshop

on

Distributed

Object

Management

August

W.

Weihl

Commutativity-Based

Concurrency

Control

for

Abstract

Data

Types

IEEE

Trans

on

Computers

-LRB-

-RRB-

December

W.

Weihl

Local

atomicity

properties

Modular

Concurrency

Control

for

Abstract

Data

Types

ACM

Trans

on

Programming

Languages

and

Systems

-LRB-

-RRB-

H.

Wachter

and

A.

Reuter

Contracts

A

means

for

Extending

Control

Beyond

Transaction

Boundaries

Advanced

Transaction

Models

for

New

Applications

A.

Elmagarmid

-LRB-

ed

-RRB-

Morgan-Kaufmann

breakpoints
extended transactions
recoverability
serializability
successions
transaction dependencies
workflows