Delegation

Efficiently

Rewriting

Historyy

Cris

Pedregal

Martin

and

Krithi

Ramamritham

Department

of

Computer

Science

University

of

Massachusetts

Amherst

Mass.

-LCB-

fcris,krithig@cs.umass.edu

Technical

Report

October

Abstract

The

notion

of

transaction

delegation

as

introduced

in

ACTA

allows

a

transaction

to

transfer

responsibility

for

the

operations

that

it

has

performed

on

an

object

to

another

transaction

Delegation

can

be

used

to

broaden

the

visibility

of

the

delegatee

and

to

tailor

the

recovery

properties

of

a

transaction

model

Delegation

has

been

shown

to

be

useful

in

synthesizing

Extended

Transaction

Models

With

an

efficient

implementation

of

delegation

it

becomes

practicable

to

realize

various

Extended

Transaction

Models

whose

requirements

are

specified

at

a

high

level

language

instead

of

the

current

expensive

practice

of

building

them

from

scratch

In

this

paper

we

identify

the

issues

in

efficiently

supporting

delegation

and

hence

extended

transaction

models

and

illustrate

our

solution

in

ARIES

an

industrial-quality

system

that

uses

undo/redo

recovery

Since

delegation

is

tantamount

to

rewriting

history

a

ve

implementation

entails

frequent

and

costly

log

accesses

and

complicates

recovery

protocols

Our

algorithm

achieves

the

effect

of

rewriting

history

without

rewriting

the

history

i.e.

the

log

resulting

in

implementations

that

realize

the

semantics

of

delegation

at

minimal

additional

overhead

and

incur

no

overhead

when

delegation

is

not

used

Besides

showing

its

efficient

application

to

ARIES

we

also

show

the

correctness

of

the

implementation

of

delegation

Our

work

indicates

that

it

is

feasible

to

build

efficient

and

robust

general-purpose

machinery

for

Extended

Transaction

Models

It

also

leads

toward

making

recovery

a

first-class

concept

within

Extended

Transaction

Models

y

Supported

in

part

by

grants

from

Sun

Microsystems

and

the

National

Science

Foundation

Contents

Introduction

Delegation

Concepts

Properties

Examples

What

Concepts

and

Properties

Assumptions

and

Notation

Properties

Why

Synthesizing

Extended

Transaction

Models

-LCB-

Examples

Split

Transactions

Nested

Transactions

How

Rewriting

History

Efficiently

Operational

Semantics

Implementing

Delegation

Efficiently

Conventional

Recovery

ARIES

Data

Structures

Normal

Processing

Recovery

Forward

Pass

Backward

Pass

Implementing

delegation

in

EOS

Discussion

Correctness

Efficiency

Related

Work

Conclusions

Introduction

The

transaction

model

adopted

in

traditional

database

systems

has

proven

inadequate

for

novel

applications

of

growing

importance

such

as

those

that

involve

reactive

-LRB-

endless

-RRB-

open-ended

-LRB-

long-lived

-RRB-

and

collaborative

-LRB-

interactive

-RRB-

activities

Various

Extended

Transaction

Models

-LRB-

ETMs

-RRB-

have

been

proposed

-LSB-

-RSB-

each

custom

built

for

the

application

it

addresses

alas

no

one

extension

is

of

universal

applicability

To

address

this

problem

we

have

been

investigating

how

to

create

general-purpose

and

robust

support

for

the

specification

and

implementation

of

diverse

Extended

Transaction

Models

Our

strategy

has

been

to

work

from

first

principles

first

identifying

the

basic

elements

that

give

rise

to

different

models

and

showing

how

to

realize

various

Extended

Transaction

Models

using

these

elements

and

then

proposing

mechanisms

for

implementing

these

elements

A

first

step

was

ACTA

-LSB-

-RSB-

that

identified

in

a

formal

framework

the

essential

components

of

Extended

Transaction

Models

In

more

operational

terms

ASSET

-LSB-

-RSB-

provided

a

set

of

new

language

primitives

that

enable

the

realization

of

various

Extended

Transaction

Models

in

an

object-oriented

database

setting

In

addition

to

the

standard

primitives

Initiate

-LRB-

to

initialize

a

transaction

-RRB-

Begin

Abort

and

Commit

ASSET

provides

three

new

primitives

form-dependency

to

establish

structure-related

inter-transaction

dependencies

permit

to

allow

for

data

sharing

without

forming

inter-transaction

dependencies

and

delegate

which

allows

a

transaction

to

transfer

responsibility

for

an

operation

to

another

transaction

Traditionally

the

transaction

invoking

an

operation

is

also

responsible

for

committing

or

aborting

that

operation

Delegation

separates

these

two

concerns

so

that

the

invoker

of

the

operation

and

the

transaction

that

commits

-LRB-

or

aborts

-RRB-

the

operation

may

be

different

In

effect

to

delegate

is

to

rewrite

history

because

a

delegation

makes

it

appear

as

if

the

delegatee

transaction

had

been

responsible

for

the

delegated

object

all

along

and

the

delegator

had

nothing

to

do

with

it

Delegation

is

useful

in

synthesizing

Extended

Transaction

Models

because

it

broadens

the

visibility

of

the

delegatee

and

because

it

controls

the

recovery

properties

of

the

transaction

model

The

broadening

of

visibility

is

useful

in

allowing

a

delegator

to

selectively

make

tentative

and

partial

results

as

well

as

hints

such

as

coordination

information

accessible

to

other

transactions

The

control

of

the

recovery

makes

it

possible

to

decouple

the

fate

of

an

update

from

that

of

the

transaction

that

made

the

update

for

instance

a

transaction

may

delegate

some

operations

that

will

remain

uncommitted

but

alive

after

the

delegator

transaction

aborted

Examples

of

Extended

Transaction

Models

that

can

be

synthesized

using

delegate

are

Joint

Transactions

Nested

Transactions

Split

Transactions

and

Open

Nested

Transactions

-LSB-

-RSB-

Biliris

et

al.

-LSB-

-RSB-

gave

a

high-level

description

of

how

to

realize

the

three

new

ASSET

primitives

Briefly

permit

is

done

by

suitably

adding

the

permittee

transaction

to

the

object

's

access

descriptor

Form-dependency

is

done

by

adding

edges

to

the

dependency

graph

after

checking

for

certain

cycles

Whereas

the

realization

of

permit

and

form-dependency

are

rather

straight-forward

close

attention

must

be

paid

to

logging

and

recovery

issues

in

the

presence

of

delegation

This

is

because

recovery

usually

keeps

some

kind

of

system

history

-LRB-

e.g.

log

-RRB-

and

delegation

is

tantamount

to

rewriting

history

-LRB-

a

delegated

object

's

operations

appear

to

have

been

done

by

the

delegatee

-RRB-

Developing

a

robust

efficient

and

correct

implementation

of

delegation

is

the

goal

of

this

paper

Specifically

to

further

the

goal

of

providing

general

purpose

machinery

to

support

the

specification

and

implementation

of

arbitrary

Extended

Transaction

Models

we

propose

here

an

efficient

implementation

of

delegation

based

on

ARIES

-LSB-

-RSB-

-LRB-

Also

we

briefly

suggest

how

to

implement

delegation

on

EOS

-LSB-

-RSB-

-RRB-

Our

additions

allow

the

efficient

Rewriting

of

History

We

hence

call

our

implementation

ARIES/RH

By

providing

delegation

we

add

substantial

semantic

power

to

a

conventional

Transaction

Management

System

allowing

it

to

capture

various

Extended

Transaction

Models

We

efficiently

achieve

this

expressiveness

by

carefully

piggy-backing

the

delegation-related

processing

onto

the

routine

processing

During

recovery

our

algorithm

neither

adds

costly

log

sweeps

to

the

recovery

algorithm

nor

does

it

demand

the

actual

rewriting

of

history

i.e.

the

log

In

this

paper

we

argue

that

ffl

Delegation

is

a

powerful

important

primitive

for

realizing

Extended

Transaction

Models

We

describe

its

properties

and

show

how

it

can

be

used

to

manipulate

visibility

and

recovery

properties

of

transactions

ffl

It

is

possible

to

implement

delegation

in

an

industrial-strength

transaction

management

system

We

illustrate

by

extending

ARIES

We

thus

obtain

the

ETM

semantics

with

little

loss

of

efficiency

and

when

delegation

is

not

used

no

overheads

are

incurred

We

also

demonstrate

the

correctness

of

our

algorithm

The

remainder

of

the

paper

is

organized

as

follows

In

Section

we

describe

the

properties

of

delegation

and

show

how

it

can

be

used

to

synthesize

some

well-known

extended

transaction

models

In

section

we

develop

delegation

in

the

context

of

a

robust

industrial-grade

transaction

management

system

First

we

explain

delegation

's

semantics

in

terms

of

rewriting

history

We

then

discuss

the

needed

data

structures

and

describe

how

we

modify

both

the

normal

processing

and

the

recovery

phases

to

support

delegation

and

explain

how

to

apply

our

algorithm

to

ARIES

We

conclude

the

section

sketching

how

to

apply

the

same

ideas

to

EOS

another

transaction

management

system

In

section

we

discuss

why

our

algorithm

correctly

implements

delegation

and

why

it

does

it

efficiently

We

review

related

work

in

section

In

section

we

present

our

conclusions

and

discuss

future

work

Delegation

Concepts

Properties

Examples

In

this

section

we

examine

the

properties

of

delegation

and

present

its

application

to

extended

transaction

models

First

we

introduce

some

notation

then

we

explain

delegation

in

terms

of

visibility

and

recovery

and

then

point

out

some

important

properties

In

the

rest

of

the

section

we

present

examples

of

extended

transaction

models

and

show

how

to

synthesize

them

using

delegation

What

Concepts

and

Properties

Here

we

describe

the

properties

of

delegation

introduce

notation

and

state

our

assumptions

Assumptions

and

Notation

ffl

t

denote

transactions

ob

a

b

denote

objects

in

the

database

ffl

update

is

a

generic

operation

on

database

objects

We

write

update

-LSB-

ob

-RSB-

and

leave

other

details

of

the

update

unspecified

Updates

are

done

in-place

on

the

updated

object

Note

that

not

all

update

operations

conflict

with

each

other

ffl

delegate

-LRB-

update

-LSB-

ob

-RSB-

-RRB-

denotes

delegation

by

to

of

update

-LSB-

ob

-RSB-

ffl

Invoking

transaction

We

call

the

transaction

that

invoked

the

update

on

the

object

the

invoking

transaction

We

write

update

-LSB-

t

ob

-RSB-

when

we

wish

to

indicate

that

t

is

the

invoking

transaction

for

that

update

Updates

that

are

never

delegated

i.e.

whose

responsible

transaction

-LRB-

see

below

-RRB-

is

always

their

invoking

transaction

are

called

boring

updates

ffl

H

denotes

the

history

of

the

database

which

contains

events

such

as

delegate

and

update

with

a

partial

order

indicated

ffl

where

ffl

precedes

Operation

invocations

are

events

ffl

ResponsibleTr

Let

transaction

t

update

object

ob

We

say

that

t

is

responsible

for

its

updates

to

ob

when

t

is

in

charge

of

changes

to

ob

More

precisely

ResponsibleTr

-LRB-

update

-LSB-

ob

-RSB-

-RRB-

t

holds

from

when

t

performs

update

-LSB-

ob

-RSB-

or

is

delegated

update

-LSB-

ob

-RSB-

until

t

either

terminates

or

delegates

update

-LSB-

ob

-RSB-

Notice

that

without

delegation

the

transaction

responsible

for

an

update

is

always

the

invoking

transaction

ffl

Op

List

The

dual

of

ResponsibleTr

is

the

Op

List

It

contains

the

operations

a

transaction

is

responsible

for

Op

List

-LRB-

t

-RRB-

fupdate

-LSB-

ob

-RSB-

j

ResponsibleTr

-LRB-

update

-LSB-

ob

-RSB-

-RRB-

tg

Properties

Pre

and

Postconditions

When

executes

delegate

-LRB-

update

-LSB-

ob

-RSB-

-RRB-

we

say

that

transfers

its

responsibility

for

update

-LSB-

ob

-RSB-

to

transaction

i.e.

ffl

pre

-LRB-

delegate

-LRB-

update

-LSB-

ob

-RSB-

-RRB-

-RRB-

-RRB-

-LRB-

ResponsibleTr

-LRB-

update

-LSB-

ob

-RSB-

-RRB-

-RRB-

must

be

the

transaction

responsible

for

update

-LSB-

ob

-RSB-

in

order

to

delegate

the

update

updates

are

boring

in

the

absence

of

delegation

ffl

post

-LRB-

delegate

-LRB-

update

-LSB-

ob

-RSB-

-RRB-

-RRB-

-RRB-

-LRB-

ResponsibleTr

-LRB-

update

-LSB-

ob

-RSB-

-RRB-

-RRB-

After

delegates

update

-LSB-

ob

-RSB-

to

becomes

the

responsible

transaction

for

the

update

Operation

delegate

-LRB-

update

-LSB-

ob

-RSB-

-RRB-

is

well

formed

when

and

are

initiated

and

not

terminated

and

is

responsible

for

update

-LSB-

ob

-RSB-

Commit/Abort

of

Updates

In

the

presence

of

delegation

the

fate

of

updates

to

an

object

is

not

necessarily

linked

to

the

transaction

which

made

the

updates

but

instead

it

is

linked

to

the

fate

of

the

transaction

to

which

the

operation

was

last

delegated

For

instance

if

does

update

-LSB-

ob

-RSB-

then

delegates

update

-LSB-

ob

-RSB-

to

and

subsequently

aborts

the

changes

made

to

ob

via

update

-LSB-

ob

-RSB-

will

still

survive

if

commits

while

it

is

still

responsible

for

update

-LSB-

ob

-RSB-

i.e.

ffl

-LRB-

Commit

-LRB-

t

-RRB-

H

-RRB-

-RRB-

-LRB-

-LSB-

ob

-RSB-

Op

List

-LRB-

t

-RRB-

-LRB-

committ

-LRB-

update

-LSB-

ob

-RSB-

-RRB-

H

-RRB-

-RRB-

-LRB-

-LRB-

-LSB-

ob

-RSB-

Op

List

-LRB-

t

-RRB-

committ

-LRB-

update

-LSB-

ob

-RSB-

-RRB-

H

-RRB-

-RRB-

-LRB-

Commit

-LRB-

t

-RRB-

H

-RRB-

-RRB-

That

transaction

t

commits

means

that

all

of

the

updates

in

its

Op

List

must

be

committed

Notice

that

these

are

the

updates

for

which

t

is

responsible

ffl

-LRB-

Abort

-LRB-

t

-RRB-

H

-RRB-

-LRB-

-LSB-

ob

-RSB-

Op

List

-LRB-

t

-RRB-

-LRB-

abortt

-LRB-

update

-LSB-

ob

-RSB-

-RRB-

H

-RRB-

-RRB-

That

transaction

t

aborts

requires

that

all

of

the

updates

it

is

responsible

for

-LRB-

i.e.

those

in

its

Op

List

-RRB-

will

be

aborted

The

events

Commit

-LRB-

t

-RRB-

and

Abort

-LRB-

t

-RRB-

denote

the

commit

and

abort

of

transaction

t

and

committ

-LRB-

update

-LSB-

ob

-RSB-

-RRB-

and

abortt

-LRB-

update

-LSB-

ob

-RSB-

-RRB-

indicate

the

permanence

or

obliteration

of

the

changes

done

by

update

-LSB-

ob

-RSB-

In

the

presence

of

delegation

the

changes

may

have

been

made

by

either

t

or

other

transaction

-LRB-

s

-RRB-

which

eventually

delegated

update

-LSB-

ob

-RSB-

to

t.

Concurrent

Delegations

An

operation

can

be

delegated

only

by

the

transaction

that

is

responsible

for

it

Since

ResponsibleT

r

-LRB-

update

-LSB-

ob

-RSB-

-RRB-

is

at

any

given

time

unique

only

one

transaction

can

delegate

an

operation

at

any

point

in

time

Thus

while

a

history

may

contain

two

or

more

delegations

of

the

same

operation

by

different

transactions

the

delegations

for

the

same

operation

can

not

occur

concurrently

Granularity

delegating

one

operation

vs.

set

of

operations

In

what

we

have

discussed

a

transaction

delegates

a

single

operation

with

each

invocation

of

delegate

Delegation

of

a

set

of

operations

in

a

single

invocation

can

be

considered

as

the

atomic

invocation

of

multiple

delegations

one

for

each

of

the

operations

in

the

set

Delegating

an

object

is

tantamount

to

delegating

all

the

operations

on

that

object

In

our

implementation

we

consider

the

delegation

of

objects

because

in

a

majority

of

practical

situations

that

we

have

come

across

delegation

occurs

at

the

granularity

of

objects

Also

in

the

examples

discussed

in

the

next

subsection

transactions

delegate

objects

Note

that

it

is

possible

for

several

transactions

to

update

an

object

concurrently

-LRB-

say

when

the

updates

commute

-RRB-

Delegation

of

one

such

operation

by

one

of

the

concurrent

transactions

only

delegates

that

transaction

's

operation

on

the

object

The

other

transactions

operations

are

not

affected

Similarly

when

a

transaction

delegates

an

object

only

that

transaction

's

operations

on

the

object

are

delegated

Also

note

that

a

transaction

can

perform

operations

on

an

object

even

after

it

has

delegated

-LRB-

an

operation

on

-RRB-

that

object

Of

course

since

after

delegation

the

system

considers

the

delegated

operations

to

have

been

done

by

the

delegatee

a

transaction

's

new

operation

may

conflict

with

one

of

its

own

one

which

has

been

delegated

Why

Synthesizing

Extended

Transaction

Models

-LCB-

Examples

In

this

section

we

motivate

delegation

through

examples

of

its

application

in

the

synthesis

of

two

extended

transaction

models

split/join

transactions

and

nested

transactions

Inheritance

in

Nested

Transactions

-LSB-

-RSB-

is

an

instance

of

delegation

Delegation

from

a

child

transaction

tc

to

its

parent

tp

occurs

when

tc

commits

This

is

achieved

through

the

delegation

of

all

the

changes

done

by

tc

to

tp

when

tc

commits

That

is

all

the

changes

that

a

child

transaction

is

responsible

for

are

delegated

to

its

parent

when

the

child

commits

A

transaction

can

delegate

at

any

point

during

its

execution

not

just

when

it

aborts

or

commits

For

instance

in

Split

Transactions

-LSB-

-RSB-

a

transaction

may

split

into

two

transactions

a

splitting

and

a

split

transaction

at

any

point

during

its

execution

A

splitting

transaction

may

delegate

to

the

split

transaction

some

of

its

operations

at

the

time

of

the

split

Thus

a

split

transaction

can

affect

objects

in

the

database

by

committing

and

aborting

the

delegated

operations

even

without

invoking

any

operation

on

the

objects

In

the

remainder

of

this

section

we

show

the

code

for

split

and

nested

transactions

synthesized

using

delegation

and

the

other

ASSET

primitives

Other

transaction

models

using

delegation

include

Reporting

Transactions

and

Co-Transactions

described

in

-LSB-

-RSB-

The

former

periodically

reports

to

other

transactions

by

delegating

its

current

results

In

the

latter

control

is

passed

from

one

transaction

to

the

other

transaction

at

the

time

of

delegation

Split

Transactions

In

the

split

transaction

model

-LSB-

-RSB-

a

transaction

can

split

into

two

transactions

and

Operations

invoked

by

on

objects

in

a

set

ob

set

are

delegated

to

and

can

now

commit

or

abort

independently

Conversely

two

transactions

say

and

can

join

to

form

one

transaction

Consider

the

following

code

used

by

to

split

off

transaction

-LRB-

the

code

for

is

that

of

function

f

-RRB-

initiate

-LRB-

f

-RRB-

delegate

-LRB-

self

-LRB-

-RRB-

-RRB-

self

returns

begin

-LRB-

-RRB-

can

join

by

executing

wait

-LRB-

-RRB-

delegate

-LRB-

-RRB-

delegates

all

objects

Nested

Transactions

Nested

transactions

are

among

the

first

extended

transaction

models

they

are

discussed

by

Moss

-LSB-

-RSB-

A

nested

transaction

consists

of

a

root

-LRB-

or

parent

-RRB-

transaction

and

nested

component

transactions

called

subtransactions

The

subtransactions

can

themselves

be

nested

transactions

Subtransactions

execute

atomically

with

respect

to

their

siblings

and

are

failure

atomic

with

respect

to

their

parent

That

is

they

can

abort

without

causing

the

whole

transaction

to

abort

A

subtransaction

can

potentially

access

any

object

that

is

currently

accessed

by

one

of

its

ancestor

transactions

without

creating

a

conflict

Abort

semantics

for

both

root

transactions

and

subtransactions

are

similar

to

abort

semantics

in

atomic

transactions

Commit

however

has

different

semantics

for

the

root

and

the

subtransactions

When

a

subtransaction

commits

the

objects

modified

by

it

are

made

accessible

to

its

parent

transaction

The

effects

on

objects

are

only

made

permanent

on

the

commit

of

the

topmost

root

transaction

We

illustrate

how

nested

transactions

are

translated

into

the

ASSET

primitives

with

a

simple

two-level

example

of

trip

arrangements

tid

t

t

trans

-LCB-

trans

-LCB-

-LRB-

-RRB-

-RCB-

trans

-LCB-

-LRB-

-RRB-

-RCB-

-RCB-

If

the

airline

reservation

fails

then

the

trip

is

canceled

If

the

hotel

reservation

fails

the

trip

is

canceled

too

and

the

effects

of

the

airline

reservation

should

not

be

made

permanent

The

nested

transaction

above

is

translated

into

tid

t

t

initiate

-LRB-

trip

-RRB-

begin

-LRB-

t

-RRB-

commit

-LRB-

t

-RRB-

where

the

function

trip

is

void

trip

-LRB-

-RRB-

-LCB-

tid

initiate

-LRB-

-RRB-

permit

-LRB-

self

-LRB-

-RRB-

-RRB-

begin

-LRB-

-RRB-

if

-LRB-

wait

-LRB-

-RRB-

-RRB-

abort

-LRB-

self

-LRB-

-RRB-

-RRB-

delegate

-LRB-

self

-LRB-

-RRB-

-RRB-

commit

-LRB-

-RRB-

tid

initiate

-LRB-

-RRB-

begin

-LRB-

-RRB-

if

-LRB-

wait

-LRB-

-RRB-

-RRB-

abort

-LRB-

self

-LRB-

-RRB-

-RRB-

delegate

-LRB-

self

-LRB-

-RRB-

-RRB-

commit

-LRB-

-RRB-

-RCB-

We

assume

that

and

will

each

abort

if

they

are

unsuccessful

If

they

succeed

they

delegate

their

updates

to

t.

Otherwise

any

updates

made

so

far

are

discarded

Note

that

after

it

has

delegated

all

its

changes

the

fate

of

a

reservation

transaction

does

not

matter

How

Rewriting

History

Efficiently

In

this

section

we

discuss

how

to

efficiently

implement

delegation

and

present

our

algorithm

RH

-LRB-

rewrite

history

-RRB-

as

follows

In

we

introduce

the

operational

semantics

of

delegation

in

the

context

of

a

generic

Database

System

-LRB-

DBS

-RRB-

In

we

examine

alternative

solutions

and

give

an

overview

of

our

algorithm

In

we

set

the

stage

with

an

overview

of

ARIES

whose

undo/redo

protocol

requires

two

passes

one

forward

and

one

backward

over

the

log

The

following

subsections

explain

the

algorithm

ARIES/RH

in

detail

we

present

the

data

structures

involved

in

then

we

describe

in

what

ARIES/RH

does

during

normal

processing

In

we

discuss

how

ARIES/RH

's

recovery

realizes

delegation

efficiently

using

the

same

passes

over

the

log

as

ARIES

We

end

the

section

in

with

an

overview

of

how

to

apply

RH

to

a

different

recovery

protocol

no-undo/redo

as

exemplified

by

EOS

Operational

Semantics

In

a

DBS

the

log

is

the

system

's

history

as

it

contains

the

records

of

all

updates

and

transactional

operations

The

idea

of

delegation

is

to

rewrite

history

selectively

altering

the

log

Suppose

that

delegate

-LRB-

ob

-RRB-

is

the

first

delegation

of

ob

by

Applying

this

delegation

can

be

visualized

as

iterating

through

the

log

into

the

past

modifying

the

records

pertaining

to

ob

so

that

each

record

of

an

access

to

ob

by

will

now

show

that

the

access

was

done

by

K

currLSN

-LRB-

LSN

of

delegate

record

-RRB-

while

LOG

-LSB-

K

-RSB-

is

not

the

initiate

record

for

if

LOG

-LSB-

K

-RSB-

is

an

update

to

ob

by

then

setTransID

-LRB-

K

-RRB-

alter

it

to

look

done

by

K

prevLSN

-LRB-

K

-RRB-

follow

's

BC

Figure

Operational

semantics

of

delegate

-LRB-

ob

-RRB-

The

log

is

a

list

held

in

stable

storage

whose

elements

are

identified

by

monotonically

increasing

values

of

the

Log

Sequence

Number

-LRB-

LSN

-RRB-

During

normal

execution

the

only

valid

operation

is

appending

a

log

record

to

the

end

of

the

log

-LRB-

with

the

corresponding

increment

of

the

current

Log

Sequence

Number

-RRB-

During

recovery

the

log

can

be

rolled

back

and

replayed

by

going

to

the

LSN

of

the

last

checkpoint

and

extracting

sequentially

the

records

from

there

on

Figure

gives

the

operational

description

of

delegation

in

terms

of

the

log

for

a

scenario

where

K

indicates

the

LSN

being

operated

on

in

the

current

iteration

Records

have

a

PrevLSN

field

that

contains

the

LSN

of

the

previous

record

for

the

same

transaction

The

chain

formed

by

the

previous

LSN

pointers

of

log

records

of

a

transaction

is

called

Backward

Chain

-LRB-

see

-RRB-

The

delegate

record

is

a

new

type

that

records

a

delegation

with

pointers

to

the

previous

records

of

both

the

delegator

and

delegatee

-LRB-

see

section

-RRB-

In

figure

we

use

the

following

operations

on

the

log

prevLSN

-LRB-

K

-RRB-

which

returns

the

Log

Sequence

Number

of

the

previous

-LRB-

most

recent

-RRB-

log

record

written

by

-LRB-

i.e.

before

or

to

the

left

of

K

-RRB-

setTransID

-LRB-

K

-RRB-

which

does

LOG

-LSB-

K

-RSB-

TransID

making

the

record

appear

as

if

it

had

been

written

by

the

transaction

The

fields

in

a

log

record

are

LSN

-LRB-

log-sequence

number

-RRB-

Type

-LRB-

update

delegation

commit

etc.

-RRB-

Trans-ID

-LRB-

the

ID

of

the

transaction

that

created

the

record

-RRB-

and

Data

For

delegate

records

there

also

exist

two

LSN

pointers

to

the

delegator

and

delegatee

-LRB-

see

-RRB-

Example

Consider

the

log

fragment

-LRB-

see

figure

-RRB-

update

-LSB-

a

-RSB-

update

-LSB-

x

-RSB-

update

-LSB-

a

-RSB-

update

-LSB-

b

-RSB-

update

-LSB-

a

-RSB-

update

-LSB-

y

-RSB-

After

the

application

of

delegate

-LRB-

a

-RRB-

the

log

looks

like

update

-LSB-

a

-RSB-

update

-LSB-

x

-RSB-

update

-LSB-

a

-RSB-

update

-LSB-

b

-RSB-

update

-LSB-

a

-RSB-

update

-LSB-

y

-RSB-

aupdate

y

a

update

delegate

abupdate

update

t

a

x

update

update

100 101 102 103

aupdate

a

y

abupdate

update

update

delegate

a

x

update

update

100 101 102 103

104 105 106

time

after

rewriting

before

rewriting

Figure

Delegation

Log

Example

Implementing

Delegation

Efficiently

The

idea

of

rewriting

history

by

modifying

the

log

is

simple

but

its

implementation

is

not

The

ve

implementation

of

the

algorithm

in

figure

would

be

to

apply

each

delegation

to

the

log

as

it

is

issued

That

is

every

time

a

delegation

is

issued

the

system

traverses

the

log

backwards

modifying

the

records

pertaining

to

the

object

being

delegated

This

eager

approach

carries

high

performance

costs

and

is

also

hard

to

prove

correct

The

performance

penalty

is

due

to

the

random

nature

of

the

accesses

-LRB-

as

opposed

to

the

usual

append-only

to

logs

-RRB-

and

the

fact

that

a

single

delegation

will

generate

many

accesses

in

principle

sweeping

the

whole

log

-LSB-

-RSB-

Ensuring

recovery

correctness

is

hard

because

we

manipulate

the

log

outside

the

usual

append-only

mode

complicating

the

model

with

extra

data

whose

integrity

in

the

face

of

crashes

is

not

guaranteed

by

the

standard

recovery

algorithm

and

must

be

ensured

ad-hoc

A

better

approach

may

be

to

use

a

lazy

algorithm

that

defers

the

alteration

of

the

log

to

recovery

This

is

based

on

the

observation

that

during

normal

processing

it

is

not

necessary

to

have

the

delegations

applied

to

the

log

The

algorithm

can

keep

track

of

the

effect

of

delegations

in

volatile

data

structures

and

log

the

delegations

to

have

the

necessary

information

after

a

crash

It

modifies

the

log

-LCB-

rewrites

history

-LCB-

during

recovery

which

manipulates

the

log

anyway

based

on

the

information

on

the

log

about

updates

and

delegations

For

example

in

undo/redo

-LRB-

see

section

-RRB-

the

algorithm

uses

the

logged

information

on

updates

and

delegations

to

reconstruct

the

information

about

delegations

during

the

analysis/redo

-LRB-

forward

-RRB-

pass

Then

in

the

undo

-LRB-

backward

-RRB-

pass

it

modifies

the

log

as

suggested

in

section

and

figure

moving

records

from

the

delegator

's

backward

chain

to

the

delegatee

's

and

rewriting

the

record

to

make

it

appear

as

if

created

by

the

delegatee

Although

this

is

workable

it

still

suffers

from

drawbacks

Because

it

modifies

the

log

in

other

than

append

mode

issues

of

correctness

in

the

face

of

failure

and

performance

must

be

addressed

It

is

possible

to

solve

the

correctness

problem

by

ensuring

that

each

BC

switch

data

information

accessed

by

transactions

that

is

not

part

of

the

database

schema

for

example

the

log

the

system

clock

wait-for

graph

Gehani

et

al.

-LSB-

-RSB-

discuss

the

issues

of

correctness

with

extra

data

Analysis

Redo

All

Undo

Losers

PASSES

Checkpoint

Failure

LOG

Failure

Figure

ARIES

passes

over

the

log

is

done

atomically

The

performance

however

is

inherently

hostage

to

the

way

the

log

is

accessed

Recall

that

in

general

the

log

does

not

fit

into

volatile

storage

The

buffering

can

result

in

thrashing

as

the

algorithm

needs

to

jump

over

possibly

large

sections

of

the

log

to

follow

backward

chain

pointers

To

avoid

these

pitfalls

we

propose

RH

a

lazy

algorithm

for

rewriting

history

that

does

not

modify

the

log

We

give

a

brief

overview

here

As

pointed

out

before

delegation

can

be

supported

easily

during

normal

processing

During

normal

processing

we

use

a

volatile

table

to

keep

track

of

which

objects

are

updated

by

which

transactions

When

a

delegation

happens

we

change

the

corresponding

object

binding

and

log

delegations

to

be

able

to

reproduce

the

change

after

the

crash

During

recovery

on

encountering

delegations

during

the

log

sweeps

we

reconstruct

the

bindings

between

operations

on

objects

and

transactions

but

do

not

actually

rewrite

the

log

records

We

rewrite

the

history

of

the

system

not

by

modifying

the

log

but

by

interpreting

the

log

during

recovery

according

to

the

delegations

That

is

we

obtain

the

desired

semantics

-LCB-

rewrite

of

the

history

according

to

the

delegations

-LCB-

without

having

to

actually

rewrite

the

log

Conventional

Recovery

ARIES

Before

going

into

the

details

of

the

algorithm

to

implement

delegation

we

present

the

conventional

version

of

ARIES

to

establish

context

and

terminology

ARIES

uses

an

undo/redo

protocol

which

means

that

after

a

crash

some

updates

will

be

undone

and

some

redone

according

to

whether

the

responsible

transaction

is

a

winner

or

loser

ARIES

scans

the

log

in

one

or

two

forward

passes

analysis

and

redo

and

then

a

backward

pass

undo

See

figure

The

Analysis

pass

starts

at

the

last

checkpoint

updates

the

information

on

active

transactions

and

dirty

pages

up

to

the

end

of

the

log

and

also

determines

the

loser

transactions

to

be

rolled

back

in

the

undo

pass

The

Redo

pass

repeats

history

writing

to

the

database

those

updates

that

had

been

posted

to

the

log

but

not

applied

before

the

crash

This

re-establishes

the

state

of

the

database

at

failure

time

including

uncommitted

updates

Because

some

ARIES

is

easier

to

tolerate

unusual

log

manipulations

during

recovery

than

during

normal

processing

problems

of

this

approach

are

discussed

in

detail

in

-LSB-

-RSB-

aupdate

y

a

update

delegate

abupdate

update

t

BC

-LRB-

-RRB-

BC

-LRB-

-RRB-

time

a

x

update

update

100 101 102 103

104 105 106

Figure

Backward

Chains

in

the

log

variants

merge

the

analysis

and

redo

passes

in

a

single

forward

pass

ARIES/RH

relies

on

a

single

forward

pass

to

add

delegation

The

Undo

pass

rolls

back

all

the

updates

by

loser

transactions

in

reverse

chronological

order

starting

with

the

last

record

of

the

log

To

facilitate

its

undo/redo

recovery

ARIES

keeps

for

each

transaction

a

Backward

Chain

-LRB-

BC

-RRB-

linking

the

transaction

's

records

in

the

log

That

is

all

the

log

records

pertaining

to

one

transaction

form

a

linked

list

beginning

with

the

most

recent

one

which

is

accessible

through

the

T

r

List

By

following

the

BC

ARIES

's

recovery

avoids

repeating

undos

as

it

can

insert

compensation

log

records

-LRB-

CLRs

-RRB-

to

indicate

how

to

undo

an

action

or

whether

to

skip

an

already

undone

action

In

terms

of

Backward

Chains

applying

delegate

-LRB-

ob

-RRB-

is

tantamount

to

removing

the

subchain

of

records

of

operations

on

ob

from

BC

-LRB-

-RRB-

merging

it

with

BC

-LRB-

-RRB-

In

the

remainder

of

this

section

we

explain

ARIES/RH

our

extension

to

ARIES

for

delegation

in

detail

We

present

the

data

structures

and

we

indicate

how

the

normal

processing

keeps

the

tables

up

to

date

We

then

examine

recovery

processing

first

the

forward

-LRB-

analysis

redo

-RRB-

pass

and

then

the

backward

-LRB-

undo

-RRB-

pass

Finally

we

examine

how

to

apply

RH

to

a

different

recovery

protocol

no-undo/redo

as

exemplified

by

EOS

Data

Structures

For

each

transaction

we

must

know

which

operations

on

which

objects

it

is

responsible

for

i.e.

its

Op

List

To

that

end

we

augment

Transaction

List

and

each

transaction

's

Object

List

found

in

conventional

DBSs

We

also

add

a

delegate

type

log

record

Tr

List

We

use

the

standard

Transaction

List

T

r

List

-LSB-

-RSB-

that

contains

for

each

Trans-ID

the

LSN

for

the

most

recent

record

written

on

behalf

of

that

transaction

and

during

recovery

whether

a

transaction

is

a

winner

or

a

loser

-LRB-

see

-RRB-

Notice

that

for

each

transaction

t

T

r

List

-LRB-

t

-RRB-

contains

the

head

of

the

backward

chain

BC

-LRB-

t

-RRB-

Figure

shows

the

backward

chains

in

the

delegation

example

of

section

-LRB-

-RRB-

a

-LRB-

t

-RRB-

object

b

Scopes

-LRB-

-RRB-

t

t

Scopes

-LRB-

-RRB-

-RRB-

-LRB-

-LRB-

-RRB-

-LRB-

t

-RRB-

axy

object

Figure

Object

Lists

after

applying

delegation

of

Example

Ob

List

Conventionally

associated

with

each

transaction

t

there

is

a

set

Ob

List

-LRB-

t

-RRB-

In

figure

Ob

List

-LRB-

-RRB-

contains

the

objects

is

currently

accessing

In

terms

of

Op

List

-LRB-

see

-RRB-

Ob

List

-LRB-

t

-RRB-

fob

j

-LSB-

ob

-RSB-

Op

List

-LRB-

t

-RRB-

g

that

is

the

objects

for

which

there

is

an

update

that

t

is

responsible

for

Note

that

the

update

may

have

been

originally

done

by

and

the

responsibility

transferred

via

delegation

Because

transactions

are

responsible

for

specific

updates

and

not

a

whole

object

a

certain

object

may

appear

in

more

than

one

Ob

List

-LRB-

but

the

associated

updates

will

be

different

-RRB-

For

example

this

can

occur

in

the

case

of

non-conflicting

updates

e.g.

increments

of

a

counter

We

identify

the

updates

that

a

transaction

is

responsible

for

by

introducing

the

notion

of

scope

-LRB-

The

scope

supports

the

notion

of

Op

List

-RRB-

Example

Consider

a

transaction

t

that

updates

ob

then

delegates

to

then

again

updates

ob

and

finally

delegates

it

to

update

-LSB-

t

ob

-RSB-

delegate

-LRB-

t

ob

-RRB-

update

-LSB-

t

ob

-RSB-

delegate

-LRB-

t

ob

-RRB-

abort

-LRB-

-RRB-

commit

-LRB-

-RRB-

Regardless

of

t

's

fate

if

commits

and

aborts

the

first

update

-LRB-

delegated

to

-RRB-

must

persist

whereas

the

second

-LRB-

to

-RRB-

must

be

undone

For

each

object

ob

in

Ob

List

-LRB-

-RRB-

there

is

a

set

of

scopes

stored

in

the

field

Scopes

covering

the

updates

to

that

object

that

is

currently

responsible

for

A

scope

is

of

the

form

-LRB-

-RRB-

-LRB-

see

figure

-RRB-

is

the

transaction

that

actually

did

the

operations

-LRB-

the

invoking

transaction

-RRB-

The

other

two

are

LSN

values

is

the

first

and

the

last

LSN

in

the

range

of

log

records

that

comprise

the

scope

See

figure

This

indicates

that

is

responsible

for

all

updates

to

ob

-LRB-

by

-RRB-

between

the

two

LSNs

Delegate

Log

Records

We

also

introduce

a

new

log

record

type

delegate

Its

type-specific

some

implementations

Ob

List

may

have

pointers

to

locks

on

the

objects

that

delegate

-LRB-

t

ob

-RRB-

really

delegates

the

updates

to

ob

that

t

is

responsible

for

allows

us

to

compute

ResponsibleT

r

-LRB-

and

Op

List

-RRB-

without

having

to

store/update

it

with

each

update

field

name

function

LSN

position

within

the

LOG

tor

transaction

id

of

delegator

torBC

delegator

's

backward

chain

tee

transaction

id

of

delegatee

teeBC

delegatee

's

backward

chain

Figure

Fields

of

the

delegate

log

record

fields

record

the

two

transactions

and

object

involved

in

the

delegation

-LRB-

see

-RRB-

The

fields

are

shown

in

figure

The

other

record

types

are

not

modified

and

are

as

discussed

in

Normal

Processing

Our

algorithm

augments

the

normal

processing

of

ARIES

we

focus

on

the

changes

entailed

by

delegation

We

describe

ARIES/RH

in

terms

of

how

different

events

are

processed

The

current

value

of

the

log

sequence

number

is

CurrLSN

ffl

begin

-LRB-

t

-RRB-

initialize

Add

t

to

Tr

List

create

Ob

List

-LRB-

t

-RRB-

ffl

update

-LSB-

t

ob

-RSB-

adjust

scopes

If

this

is

the

first

update

t

does

on

ob

since

t

started

or

last

delegated

ob

we

must

open

a

new

scope

Otherwise

there

is

an

active

scope

of

t

on

ob

that

we

must

extend

if

ob

Ob

List

-LRB-

t

-RRB-

then

Ob

List

-LRB-

t

-RRB-

Ob

List

-LRB-

t

-RRB-

-LSB-

fobg

if

-LRB-

t

-RRB-

Ob

List

-LRB-

t

-RRB-

-LSB-

ob

-RSB-

then

Ob

List

-LRB-

t

-RRB-

-LSB-

ob

-RSB-

Scopes

-LRB-

t

CurrLSN

CurrLSN

-RRB-

-LRB-

create

new

scope

-RRB-

else

Ob

List

-LRB-

t

-RRB-

-LSB-

ob

-RSB-

Scopes

-LRB-

CurrLSN

-RRB-

-LRB-

extend

existing

scope

-RRB-

ffl

delegate

-LRB-

ob

-RRB-

well-formed

Verify

that

ob

Ob

List

-LRB-

-RRB-

which

tests

for

this

case

the

precondition

in

pre

-LRB-

delegate

-LRB-

update

-LSB-

ob

-RSB-

-RRB-

-RRB-

-RRB-

-LRB-

ResponsibleTr

-LRB-

update

-LSB-

ob

-RSB-

-RRB-

-RRB-

prepare

log

record

-LRB-

s

-RRB-

Record

delegator

delegatee

Rec

tor

Rec

tee

Link

this

log

record

into

's

and

's

backward

chains

Rec

torBC

BC

-LRB-

-RRB-

PrevLSN

Rec

teeBC

BC

-LRB-

-RRB-

PrevLSN

transfer

responsibility

Move

operations

on

ob

from

Op

List

-LRB-

-RRB-

to

Op

List

-LRB-

-RRB-

Add

ob

to

delegatee

's

Ob

List

and

record

that

ob

was

delegated

by

use

in

a

field

to

denote

we

do

not

change

it

or

are

not

interested

in

its

content

Ob

List

-LRB-

-RRB-

Ob

List

-LRB-

-RRB-

-LSB-

fobg

Ob

List

-LRB-

-RRB-

-LSB-

ob

-RSB-

deleg

Pass

delegator

's

Scopes

for

ob

to

the

delegatee

and

remove

ob

from

the

delegator

's

Ob

List

Ob

List

-LRB-

-RRB-

-LSB-

ob

-RSB-

Scopes

Ob

List

-LRB-

-RRB-

-LSB-

ob

-RSB-

Scopes

-LSB-

Ob

List

-LRB-

-RRB-

-LSB-

ob

-RSB-

Scopes

Ob

List

-LRB-

-RRB-

Ob

List

-LRB-

-RRB-

fobg

Remark

We

use

a

union

because

may

already

be

responsible

for

some

operations

on

ob

before

receiving

the

delegation

Therefore

the

Scopes

field

may

actually

contain

several

scopes

contiguous

ranges

of

LSNs

on

the

log

each

tagged

with

the

transaction

that

initially

was

responsible

for

that

scope

which

is

the

invoking

transaction

for

those

updates

-LRB-

Notice

that

the

scopes

may

overlap

on

the

log

segment

they

cover

but

can

not

share

the

same

invoking

transaction

-RRB-

write

delegation

log

record

-LRB-

s

-RRB-

Write

log

record

and

mark

it

as

the

current

head

of

the

backward

chains

of

delegator

and

delegatee

LOG

-LSB-

CurrLSN

-RSB-

Rec

BC

-LRB-

-RRB-

CurrLSN

BC

-LRB-

-RRB-

CurrLSN

ffl

commit

-LRB-

t

-RRB-

commit

operations

Write

to

the

log

the

operations

for

which

t

is

responsible

write

commit

record

Write

a

commit

record

to

the

log

after

the

operations

flush

log

Write

to

stable

storage

all

records

in

the

log

from

the

previous

flush

up

to

the

commit

record

inclusive

ffl

abort

-LRB-

t

-RRB-

abort

operations

Undo

the

updates

for

which

t

is

responsible

Recall

that

any

object

that

had

been

delegated

by

the

aborting

transaction

will

no

longer

be

in

the

transaction

's

Ob

List

unless

it

updated

it

after

the

delegation

Obtain

minLSN

min

fbegin

j

Ob

List

-LRB-

t

-RRB-

-LSB-

ob

-RSB-

Scopes

-LRB-

begin

-RRB-

g

on

objects

in

Ob

List

-LRB-

t

-RRB-

For

each

object

in

Ob

List

-LRB-

t

-RRB-

undo

all

updates

contained

in

its

Scopes

writing

to

the

log

the

compensation

log

records

going

backwards

in

the

log

until

minLSN

is

reached

write

abort

record

Write

log

abort

record

to

the

log

flush

log

Flush

log

up

to

abort

record

The

other

transactional

events

are

processed

as

usual

-LSB-

-RSB-

Recovery

After

a

crash

the

transaction

system

must

do

some

recovery

processing

to

return

to

a

consistent

state

This

entails

restoring

the

state

from

a

checkpoint

-LRB-

retrieved

from

stable

storage

-RRB-

and

using

the

log

-LRB-

also

from

stable

storage

-RRB-

to

reproduce

the

events

after

the

checkpoint

was

taken

For

simplicity

of

presentation

we

ignore

checkpoints

from

now

on

but

it

is

easy

to

see

how

data

structures

can

be

rebuilt

using

checkpoints

instead

of

going

back

to

the

beginning

Crash

is

the

event

that

represents

a

failure

RecoveryComplete

is

the

event

that

appears

in

the

history

to

indicate

that

the

recovery

is

complete

Winners

is

the

set

of

transactions

that

had

committed

before

the

crash

The

recovery

algorithm

ensures

that

their

updates

will

be

reinstalled

Losers

is

all

the

other

transactions

that

were

active

but

had

not

committed

or

had

aborted

before

the

crash

Their

updates

must

be

undone

In

the

rest

of

this

section

we

present

the

forward

pass

of

ARIES/RH

we

establish

the

state

after

that

pass

and

we

describe

the

backward

pass

Forward

Pass

ARIES

starts

with

a

forward

pass

that

finds

out

which

transactions

were

active

and

which

committed

before

the

crash

-LRB-

analysis

-RRB-

Committed

transactions

are

Winners

active

but

uncommitted

or

aborted

transactions

are

Losers

ARIES

also

uses

the

forward

pass

to

redo

logged

updates

At

the

end

of

this

pass

the

Object

Lists

are

up

to

date

including

the

s

of

the

updates

Before

the

first

pass

of

recovery

starts

Winners

Losers

OE

For

brevity

we

omit

some

details

already

explained

for

the

normal

processing

We

describe

the

treatment

of

the

log

records

matter

relevant

to

delegation

in

ARIES

Other

records

are

processed

as

usual

ffl

begin

-LRB-

t

-RRB-

initialize

Add

t

to

Tr

List

create

Ob

List

-LRB-

t

-RRB-

loser

by

default

Consider

t

a

loser

by

default

Losers

Losers

-LSB-

ftg

ffl

update

-LSB-

t

ob

-RSB-

adjust

scopes

This

is

done

just

as

update

-LRB-

-RRB-

in

normal

processing

redo

Redo

update

-LSB-

t

ob

-RSB-

ffl

delegate

-LRB-

ob

-RRB-

transfer

responsibility

This

is

done

just

as

delegate

-LRB-

-RRB-

in

normal

processing

ffl

commit

-LRB-

t

-RRB-

t

committed

and

thus

is

a

winner

commit

Declare

t

committed

Notice

that

t

's

updates

were

redone

during

this

forward

pass

winner

Declare

t

as

a

winner

Winners

Winners

-LSB-

ftg

Losers

Losers

ftg

After

the

Forward

Pass

we

have

updated

the

following

ffl

Ob

Lists

are

restored

to

their

state

before

the

crash

for

all

transactions

ffl

Winners

has

all

the

transactions

whose

updates

must

survive

-LRB-

i.e.

which

had

committed

before

the

crash

-RRB-

Losers

has

those

whose

updates

must

be

obliterated

ffl

LsrObs

includes

all

objects

in

the

Ob

Lists

of

loser

transactions

We

compute

it

after

the

forward

pass

ends

as

LsrObs

-LSB-

Ob

List

-LRB-

t

-RRB-

Backward

Pass

ARIES

undoes

exactly

all

the

updates

invoked

by

the

loser

transactions

It

follows

the

backward

chains

-LRB-

of

records

for

each

transaction

-RRB-

for

each

of

the

loser

transactions

undoing

all

their

updates

ARIES

continually

takes

the

maximum

Log

Sequence

Number

-LRB-

LSN

-RRB-

for

an

outstanding

undo

ensuring

monotonically

decreasing

-LRB-

by

LSN

-RRB-

accesses

to

the

log

with

the

attendant

efficiencies

This

approach

is

not

possible

in

the

presence

of

delegation

What

we

need

to

achieve

is

the

undo

not

of

all

the

updates

invoked

by

a

loser

transaction

but

instead

of

all

the

updates

that

were

ultimately

delegated

to

a

loser

transaction

Thus

the

analogy

to

ARIES

would

be

to

have

backward

chains

linking

those

updates

but

constructing

and

maintaining

them

is

complicated

and

expensive

One

could

scan

all

log

records

backwards

identifying

the

loser

updates

-LRB-

to

be

undone

-RRB-

which

are

the

updates

whose

responsible

transaction

is

a

loser

This

is

undesirable

as

it

entails

unnecessarily

inspecting

many

winner

updates

Fortunately

the

necessary

information

to

undo

loser

updates

efficiently

is

in

the

object

lists

of

the

loser

transactions

the

update

scopes

used

for

delegation

In

the

rest

of

the

section

we

discuss

how

undo

and

delegation

are

integrated

in

the

backward

pass

of

ARIES/RH

The

only

records

that

require

special

processing

are

update

and

delegation

all

others

are

processed

as

in

ARIES

Notice

that

by

undoing

the

loser

updates

instead

of

the

updates

invoked

by

loser

transactions

we

are

in

fact

applying

the

delegations

as

we

undo

according

to

the

fate

of

the

final

delegatee

of

each

update

As

in

ARIES

for

each

undone

update

we

write

a

Compensation

Log

Record

-LRB-

CLR

-RRB-

to

avoid

undoing

an

update

repeatedly

should

crashes

occur

during

recovery

Recall

that

scopes

keep

track

of

updates

whose

fate

is

the

same

-LRB-

i.e.

that

were

delegated

together

-RRB-

It

is

enough

to

inspect

records

within

the

loser

scopes

to

find

all

loser

updates

To

do

this

efficiently

we

introduce

the

notion

of

cluster

of

scopes

Scopes

may

overlap

a

cluster

of

scopes

is

a

maximal

set

of

overlapping

scopes

-LRB-

We

only

care

about

loser

clusters

of

scopes

so

we

omit

loser

from

now

on

-RRB-

Within

each

cluster

we

must

examine

every

log

record

but

between

clusters

we

examine

For

instance

in

figure

there

are

three

clusters

the

middle

one

contains

four

overlapping

loser

scopes

-LRB-

In

figure

loser

scopes

are

depicted

in

dark

shades

-RRB-

The

last

cluster

has

already

been

processed

and

we

are

processing

the

middle

cluster

-LRB-

K

indicates

the

current

log

record

-RRB-

The

current

cluster

begins

at

begCluster

the

first

-LRB-

i.e.

to

be

processed

last

-RRB-

cluster

in

the

log

begins

at

begLsrScopes

ARIES

all

loser

updates

are

those

invoked

by

loser

transactions

so

ARIES/RH

reduces

to

ARIES

when

there

is

no

delegation

begLsrScopes

no

loser

scopes

loser

scopes

backward

sweep

begCluster

K

current

cluster

already

done

Figure

Loser

scope

clusters

in

a

the

log

We

can

now

outline

the

algorithm

for

the

backward

pass

of

ARIES/RH

-LRB-

see

also

figure

-RRB-

The

idea

is

to

examine

each

loser

cluster

skipping

all

other

records

Within

a

cluster

we

examine

all

records

undoing

loser

updates

We

also

adjust

the

current

cluster

by

adding

or

deleting

scopes

closing

the

cluster

when

we

reach

its

first

record

at

begCluster

The

algorithm

ends

when

we

reach

the

beginning

of

the

first

cluster

at

begLsrScopes

We

begin

by

computing

the

set

LsrScopes

which

contains

all

the

scopes

for

which

loser

transactions

are

responsible

We

compute

begLsrScopes

which

marks

the

beginning

of

the

leftmost

-LRB-

oldest

-RRB-

loser

scope

in

the

log

We

start

sweeping

the

log

backwards

-LRB-

i.e.

right-to-left

in

the

figure

-RRB-

at

the

end

of

the

rightmost

loser

scope

and

end

at

begLsrScopes

-LRB-

see

while

-RRB-

This

sweep

consists

of

two

steps

we

identify

a

cluster

and

undo

all

the

loser

updates

in

its

component

scopes

-LRB-

-RRB-

and

we

move

to

the

next

cluster

once

the

current

one

is

exhausted

-LRB-

-RRB-

We

process

a

cluster

-LRB-

-RRB-

in

four

steps

First

we

check

whether

the

current

record

is

the

right

end

of

a

scope

in

which

case

we

add

the

scope

to

the

current

cluster

-LRB-

-RRB-

Then

we

check

if

the

record

is

a

loser

update

and

if

so

we

undo

it

-LRB-

-RRB-

Specifically

a

record

is

a

loser

update

if

it

is

within

the

ends

of

a

loser

scope

whose

invoking

transaction

is

the

same

as

the

update

's

invoking

transaction

Then

we

check

if

a

scope

ended

in

the

record

just

processed

in

which

case

we

remove

it

from

the

current

cluster

because

the

scope

has

already

been

treated

-LRB-

-RRB-

Finally

we

move

K

-LRB-

left

-RRB-

to

the

next

record

-LRB-

-RRB-

Since

when

we

add

a

scope

to

the

current

cluster

Cluster

-LRB-

-RRB-

we

remove

it

from

LsrScopes

-LRB-

-RRB-

finds

the

next

cluster

by

looking

at

the

remaining

scopes

in

LsrScopes

and

finding

the

rightmost

end

The

repeat

loop

ends

because

we

decrement

K

by

at

least

one

on

each

iteration

and

although

-LRB-

-RRB-

's

limit

begCluster

may

decrease

it

may

never

go

below

begLsrScopes

-LRB-

because

begLsrScopes

is

the

minimum

of

scope

begins

-RRB-

so

eventually

K

reaches

it

The

while

loop

ends

because

we

and

the

following

references

in

parentheses

are

to

figure

LsrScopes

f

scope

j

Losers

scope

Ob

List

-LRB-

t

-RRB-

-LSB-

ob

-RSB-

Scopesg

all

loser

scopes

if

LsrScopes

OE

then

begLsrScopes

min

f

left

j

-LRB-

left

-RRB-

LsrScopes

g

start

of

earliest

scope

K

max

f

right

j

-LRB-

right

-RRB-

LsrScopes

g

end

of

latest

scope

Cluster

OE

begCluster

K

while

begLsrScopes

K

K

sweeps

log

backwards

to

left

end

of

earliest

loser

scope

-LRB-

-RRB-

repeat

identify

and

process

cluster

of

overlapping

slopes

add

to

Cluster

the

loser

scope

that

ends

in

K

-LRB-

-RRB-

if

-LRB-

left

K

-RRB-

LsrScopes

then

Cluster

Cluster

-LSB-

f

-LRB-

left

K

-RRB-

g

put

in

Cluster

LsrScopes

LsrScopes

f

-LRB-

left

K

-RRB-

g

and

remove

from

LsrScopes

begCluster

min

-LRB-

left

begCluster

-RRB-

updating

where

cluster

starts

undo

if

it

is

loser

update

-LRB-

-RRB-

if

LOG

-LSB-

K

-RSB-

update

-LSB-

t

ob

-RSB-

and

-LRB-

t

-RRB-

Cluster

then

undo

-LRB-

update

-LSB-

t

ob

-RSB-

-RRB-

CLR.PrevLSN

LOG

-LSB-

K

-RSB-

PrevLSN

and

other

undo

information

discard

scope

that

begins

at

new

record

LOG

-LSB-

K

-RSB-

-LRB-

-RRB-

if

-LRB-

left

-RRB-

Cluster

and

K

left

then

already

processed

Cluster

Cluster

f

-LRB-

left

-RRB-

g

so

discard

processed

record

LOG

-LSB-

K

-RSB-

next

-LRB-

left

-RRB-

-LRB-

-RRB-

K

K

-LRB-

end

-RRB-

until

K

begCluster

finished

this

cluster

-LRB-

sweep

backwards

-RRB-

find

next

cluster

of

scopes

-LRB-

-RRB-

K

max

f

right

j

-LRB-

right

-RRB-

LsrScopesg

RecoveryComplete

Figure

Backward

pass

of

ARIES/RH

decrement

K

by

at

least

one

each

time

-LRB-

-RRB-

-LRB-

and

more

when

we

skip

between

clusters

-LRB-

-RRB-

-RRB-

Notice

that

we

visit

each

log

record

at

most

once

and

in

a

monotonically

decreasing

way

-LRB-

K

gets

decremented

by

at

least

one

in

each

iteration

of

the

while

loop

-RRB-

This

is

important

as

the

log

will

be

brought

in

from

memory

and

mimics

ARIES

's

strategy

of

continually

taking

the

largest

LSN

of

the

updates

to

be

undone

The

set

of

scopes

LsrScopes

is

constructed

once

and

depleted

in

the

reverse

order

of

scopes

so

an

efficient

data

structure

is

a

priority

queue

-LRB-

on

a

heap

-RRB-

sorted

by

right

end

of

scopes

with

the

largest

value

first

The

set

of

scopes

Cluster

is

searched

by

invoking

transaction

gains

scopes

to

the

left

and

loses

scopes

to

the

right

A

binary

tree

keyed

on

transaction

ids

is

a

reasonable

implementation

Implementing

delegation

in

EOS

Rewriting

History

can

be

applied

to

other

recovery

algorithms

for

instance

EOS

-LSB-

-RSB-

which

uses

a

no-undo/redo

protocol

Next

we

give

an

overview

of

EOS

and

then

discuss

briefly

how

to

apply

RH

to

implement

delegation

To

avoid

having

to

undo

changes

in

the

database

EOS

avoids

applying

those

changes

until

the

transaction

that

made

them

is

ready

to

commit

This

is

achieved

by

keeping

a

global

log

in

which

only

transaction

commits

are

recorded

and

per-transaction

private

logs

If

a

transaction

commits

its

private

log

is

flushed

to

stable

storage

if

it

aborts

the

private

log

is

discarded

The

recovery

of

EOS

is

simpler

than

that

of

ARIES

because

no

undo

is

necessary

only

committed

changes

are

logged

so

they

are

reapplied

during

a

single

forward

sweep

of

the

global

log

-LRB-

that

in

turn

brings

in

the

private

logs

of

committed

transactions

-RRB-

We

can

support

delegation

within

EOS

by

applying

an

algorithm

very

similar

to

ARIES/RH

for

the

normal

processing

and

the

forward

pass

of

the

recovery

The

differences

are

due

to

the

private

logs

kept

by

EOS

Rewriting

History

must

now

be

implemented

across

different

private

logs

When

two

transactions

do

concurrent

-LRB-

but

non-conflicting

-RRB-

updates

on

an

object

and

one

delegates

its

operations

to

the

other

the

net

effect

should

be

as

if

the

delegatee

had

executed

all

the

operations

in

the

original

order

In

EOS

the

transactions

keep

separate

logs

so

reconstructing

that

order

is

not

straightforward

This

situation

does

not

arise

when

we

restrict

the

operations

to

reads

and

writes

because

in

this

case

all

updates

are

translated

to

write

operations

and

so

even

compatible

update

operations

execute

in

isolation

In

the

read/write

case

then

it

is

enough

for

the

delegator

to

supply

the

delegatee

with

an

image

of

the

current

state

of

the

object

at

the

time

of

the

delegation

This

image

is

stored

as

part

of

the

delegate

record

Supporting

delegation

in

EOS

entails

logging

the

delegation

both

at

the

delegator

and

the

delegatee

The

delegator

filters

out

updates

it

has

delegated

when

it

comes

time

to

commit

to

avoid

committing

updates

it

no

longer

is

responsible

for

If

it

aborts

its

private

log

is

discarded

but

the

delegated

updates

are

preserved

in

the

log

of

the

delegatee

When

the

delegatee

commits

it

has

the

updates

it

has

received

through

delegation

preserved

in

the

delegatee

record

so

it

does

not

need

to

rely

on

the

delegator

-LRB-

which

may

not

be

around

any

more

-RRB-

If

the

delegatee

aborts

the

updates

it

received

in

delegation

will

not

be

applied

-LRB-

delegatee

's

log

is

discarded

delegator

's

is

either

discarded

or

filtered

-RRB-

Recovery

is

simple

because

we

only

need

to

redo

the

winner

updates

Loser

transactions

have

their

private

logs

discarded

and

winner

transactions

have

their

private

logs

redone

This

takes

care

of

the

undelegated

updates

For

delegated

updates

first

we

see

that

they

get

redone

if

they

were

winner

updates

-LRB-

i.e.

their

Responsible

Transaction

at

crash

time

was

a

winner

that

is

had

committed

-RRB-

Regardless

of

the

fate

of

the

invoking

transaction

-LRB-

and

any

intervening

delegating

transactions

-RRB-

the

winner

update

was

delegated

to

the

winner

transaction

last

Thus

when

redoing

the

winner

transaction

's

log

we

restore

the

state

of

the

object

from

the

delegation

record

in

the

winner

's

private

log

Notice

that

there

is

no

possibility

for

this

ever

being

undone

because

no

updates

are

ever

undone

If

an

update

was

in

a

loser

transaction

it

will

not

be

redone

because

the

loser

transaction

's

private

log

is

discarded

It

also

does

not

get

redone

by

other

transactions

for

the

following

reason

If

the

invoking

transaction

is

a

winner

it

must

have

delegated

the

update

-LRB-

for

it

to

be

a

loser

now

-RRB-

When

a

transaction

delegates

an

update

it

filters

it

out

when

saving

its

private

log

so

that

update

will

not

be

there

when

the

private

log

is

redone

This

applies

to

any

transaction

that

was

at

some

point

responsible

for

the

update

and

delegated

it

Thus

the

loser

updates

do

not

get

redone

Discussion

In

this

section

we

discuss

two

issues

with

regard

to

the

implementation

of

the

recovery

algorithm

First

we

analyze

aspects

of

the

algorithm

presented

in

section

to

show

that

it

implements

delegation

correctly

In

the

second

part

we

examine

the

implementation

and

argue

that

it

is

efficient

Correctness

To

ensure

correctness

in

a

recovery

protocol

we

must

guarantee

that

after

recovery

all

operations

by

loser

transactions

have

been

rolled

back

completely

-LRB-

their

effects

obliterated

-RRB-

and

all

by

winner

transactions

have

been

committed

-LRB-

their

effects

guaranteed

to

be

permanent

-RRB-

Conventional

ARIES

complies

with

this

by

using

the

undo/redo

protocol

-LRB-

EOS

does

noundo/redo

-RRB-

We

show

in

this

section

that

ARIES/RH

that

is

ARIES

with

our

modifications

complies

with

this

requirement

when

it

is

rephrased

to

include

delegation

That

is

operations

delegated

to

loser

transactions

will

be

aborted

and

operations

delegated

to

winner

transactions

will

be

committed

Naturally

boring

operations

-LRB-

i.e.

never

delegated

-RRB-

are

treated

as

in

the

conventional

case

because

in

the

absence

of

delegation

ARIES/RH

reduces

to

ARIES

After

the

event

Crash

we

initiate

recovery

which

ends

with

the

event

RecoveryComplete

Between

Crash

and

RecoveryComplete

all

events

are

generated

by

the

recovery

system

For

simplicity

we

ignore

checkpoints

and

assume

that

the

system

restarts

from

the

beginning

A

brief

recapitulation

of

the

algorithm

is

in

order

The

forward

pass

reads

but

does

not

write

anything

to

the

log

It

redoes

the

updates

present

in

the

log

and

constructs

the

sets

Winners

of

transactions

whose

updates

will

survive

after

the

recovery

It

also

records

the

Losers

i.e.

active

transactions

that

did

not

commit

before

the

crash

ARIES/RH

also

computes

LsrObs

after

the

forward

pass

The

backward

pass

reads

the

log

interpreting

it

according

to

the

delegations

and

undoes

updates

on

loser

objects

In

the

remainder

of

this

section

we

characterize

loser

and

winner

transactions

and

their

associated

updates

we

explain

the

idea

of

delegation

chain

and

formalize

the

correctness

properties

Then

we

show

the

correctness

of

the

algorithm

to

wit

that

all

loser

updates

get

undone

and

all

winner

updates

get

redone

Winners

Losers

LsrObs

ffl

t

Winners

-LRB-

-RRB-

-LRB-

Commit

-LRB-

t

-RRB-

Crash

-RRB-

t

is

a

winner

if

it

committed

before

the

crash

ffl

t

Losers

-LRB-

-RRB-

-LRB-

Begin

-LRB-

t

-RRB-

Crash

-LRB-

t

-RRB-

H

-RRB-

t

is

a

loser

if

it

was

active

but

did

not

commit

before

the

crash

Losers

an

active

transaction

is

by

default

a

loser

If

there

is

a

commit

record

before

the

crash

its

transaction

is

moved

to

Winners

Note

that

these

sets

are

disjoint

and

that

Losers

includes

transactions

that

had

aborted

before

the

crash

ffl

LsrObs

-LSB-

Ob

List

-LRB-

t

-RRB-

i.e.

ob

LsrObs

-RRB-

Losers

ob

Ob

List

-LRB-

t

-RRB-

LsrObs

is

the

set

of

all

objects

for

which

there

is

a

loser

transaction

that

is

responsible

for

an

update

to

that

object

This

means

that

a

loser

object

has

at

least

one

update

that

will

be

undone

Delegation

Chain

We

assert

that

if

tn

is

responsible

for

an

update

either

tn

invoked

the

update

itself

-LRB-

n

-RRB-

or

tn

received

it

from

through

a

sequence

of

delegations

Formally

update

-LSB-

ob

-RSB-

Op

List

-LRB-

tn

-RRB-

=-RRB-

-LRB-

-LRB-

n

-RRB-

tn

tn

such

that

that

is

if

tn

is

responsible

for

the

update

then

there

is

a

sequence

of

transactions

starting

with

the

invoking

transaction

and

ending

with

the

responsible

transaction

tn

such

that

-LSB-

update

-LSB-

ob

-RSB-

delegate

-LRB-

ob

-RRB-

delegate

-LRB-

tn

tn

ob

-RRB-

-RSB-

-LSB-

such

that

delegate

-LRB-

tn

tn

ob

-RRB-

delegate

-LRB-

tn

ty

ob

-RRB-

Crash

-RSB-

-LSB-

-LRB-

i

n

-RRB-

such

that

delegate

-LRB-

ti

ti

ob

-RRB-

delegate

-LRB-

ti

tx

ob

-RRB-

delegate

-LRB-

ti

ti

ob

-RRB-

-RSB-

delegated

the

update

to

and

so

on

until

finally

tn

received

it

in

the

last

delegation

and

for

each

ti

ti

is

the

first

transaction

to

which

ti

delegates

ob

i.e.

there

is

no

other

intervening

delegate

-LRB-

to

say

transaction

tx

-RRB-

of

that

update

We

prove

that

if

tn

is

responsible

for

an

update

there

is

a

sequence

of

delegations

that

links

the

original

update

log

record

to

tn

by

induction

on

n

The

base

case

for

n

is

immediate

from

the

algorithm

that

applies

delegation

during

normal

processing

and

the

forward

pass

of

recovery

Specifically

when

a

transaction

invokes

an

update

it

creates

or

enlarges

its

current

scope

to

include

it

-LRB-

see

delegate

in

-RRB-

Each

time

a

delegation

is

invoked

the

scope

of

the

delegated

object

which

includes

the

delegator

's

updates

is

passed

to

the

delegatee

-LRB-

see

delegate

in

-RRB-

The

scope

defines

uniquely

the

updates

being

delegated

-LRB-

see

Ob

List

in

and

the

remark

in

-RRB-

For

the

inductive

case

note

that

a

delegated

scope

is

never

modified

by

the

delegatee

For

a

given

object

a

delegatee

either

keeps

the

scope

-LRB-

s

-RRB-

it

received

in

the

delegation

or

it

augments

them

with

its

own

scope

for

its

updates

on

the

object

Thus

in

a

delegate

-LRB-

tk

tk

ob

-RRB-

the

scopes

that

tk

keeps

for

the

object

ob

are

Ob

List

-LRB-

tk

-RRB-

-LSB-

ob

-RSB-

Scopes

-LSB-

the

scope

tk

has

on

ob

Thus

an

update

contained

in

tk

's

scope

for

ob

will

be

in

tk

's

Correctness

Properties

Here

we

state

the

properties

of

undo

and

redo

that

describe

correct

recovery

undo

-LRB-

Losers

-LSB-

ob

-RSB-

Op

List

-LRB-

t

-RRB-

-RRB-

-LRB-

Undo

-LRB-

update

-LSB-

ob

-RSB-

-RRB-

RecoveryComplete

-RRB-

All

updates

ultimately

delegated

to

a

loser

transaction

are

undone

before

the

recovery

ends

redo

-LRB-

Winners

-LSB-

ob

-RSB-

Op

List

-LRB-

t

-RRB-

-RRB-

-LRB-

Redo

-LRB-

update

-LSB-

ob

-RSB-

-RRB-

RecoveryComplete

-RRB-

All

updates

ultimately

delegated

to

a

winner

transaction

are

redone

before

the

recovery

is

finished

In

other

words

updates

whose

responsible

transaction

did

not

commit

before

the

crash

are

undone

-LRB-

obliterated

-RRB-

and

updates

whose

responsible

transaction

committed

before

the

crash

are

redone

-LRB-

made

permanent

-RRB-

In

the

following

paragraphs

we

discuss

how

the

implementation

satisfies

the

requirements

Correctness

of

ARIES/RH

For

the

correctness

of

the

normal

processing

notice

that

the

scope

information

on

the

Ob

List

associated

with

each

transaction

is

sufficient

to

decide

whether

to

commit

or

abort

a

specific

update

in

the

absence

of

crashes

Then

notice

that

the

updates

covered

by

scopes

in

the

Ob

List

of

a

loser

transaction

are

aborted

and

those

in

the

Ob

List

of

a

winner

are

committed

This

is

easy

to

see

by

inspection

of

the

algorithm

specifically

the

update

commit

and

abort

cases

in

For

the

recovery

we

first

show

that

undo

holds

that

is

that

all

loser

updates

are

undone

An

update

is

a

loser

if

ResponsibleT

r

-LRB-

update

-LSB-

ob

-RSB-

-RRB-

t

and

t

Losers

-LRB-

We

already

know

n

reduces

to

no

delegation

and

holds

trivially

it

is

the

boring

update

case

that

there

must

be

a

delegation

chain

from

to

t.

-RRB-

This

means

that

there

is

a

scope

-LRB-

l

r

-RRB-

Ob

List

-LRB-

t

-RRB-

-LSB-

ob

-RSB-

Scopes

and

a

log

sequence

number

q

l

q

r

such

that

LOG

-LSB-

q

-RSB-

update

-LSB-

ob

-RSB-

by

the

definitions

of

scope

loser

update

and

responsible

transaction

Then

by

the

construction

of

LsrScopes

in

the

algorithm

-LRB-

figure

-RRB-

-LRB-

l

r

-RRB-

LsrScopes

Let

us

show

that

the

record

for

the

update

will

be

eventually

checked

and

undone

Initially

-LRB-

l

r

-RRB-

LsrObs

l

initial

value

of

K

and

begLsrScopes

r

by

construction

Because

K

starts

at

the

maximum

value

and

goes

down

by

one

or

jumps

to

the

next

right

end

of

a

scope

it

will

eventually

reach

r

and

put

-LRB-

l

r

-RRB-

in

Cluster

When

K

reaches

q

it

is

within

the

scope

and

the

update

is

undone

We

prove

the

redo

property

by

contradiction

Recall

that

all

updates

are

redone

in

the

forward

pass

We

show

that

no

winner

update

gets

undone

We

proceed

by

contradiction

we

suppose

that

a

winner

update

is

erroneously

undone

in

the

backward

pass

If

the

update

was

undone

it

means

that

it

appeared

in

some

loser

scope

-LRB-

see

figure

-RRB-

But

because

the

delegation

chain

applies

here

too

-LRB-

it

does

not

depend

on

the

fate

of

the

final

transaction

-RRB-

this

means

that

there

is

a

chain

of

delegations

that

starts

with

the

invoking

transaction

of

the

update

and

ends

with

a

loser

transaction

But

that

means

that

the

responsible

transaction

of

the

update

was

a

loser

contradicting

that

it

was

a

winner

update

Q.E.D.

Efficiency

We

claim

that

ARIES/RH

is

efficient

in

the

following

senses

ffl

No

delegation

no

overhead

In

the

absence

of

delegation

ARIES/RH

reduces

to

the

original

algorithm

so

no

penalty

is

incurred

due

to

the

extra

functionality

when

it

is

not

used

ffl

Normal

processing

low

overhead

Posting

one

delegation

during

normal

processing

has

the

cost

of

adding

a

log

entry

and

updating

the

object

bindings

The

cost

of

delegations

is

linear

in

the

number

of

operations

delegated

For

instance

the

updating

of

Object

Lists

for

a

delegation

is

linear

in

the

length

of

the

Ob

Lists

ffl

Recovery

low

overhead

The

costs

of

the

recovery

passes

are

similar

to

those

of

conventional

ARIES

ARIES/RH

does

not

add

any

extra

passes

For

all

operations

supporting

delegation

only

entails

costs

at

most

linear

in

the

number

of

delegated

operations

-LRB-

see

previous

item

-RRB-

Also

recovery

costs

are

dominated

by

disk

log

accesses

which

ARIES/RH

does

as

efficiently

as

ARIES

For

instance

on

the

backward

pass

log

records

are

visited

at

most

once

and

in

strict

decreasing

order

as

in

ARIES

allowing

for

the

usual

optimizations

The

first

two

points

follow

from

the

fact

that

ARIES/RH

only

adds

some

fields

to

data

structures

that

are

already

updated

by

the

conventional

algorithm

When

there

is

no

delegation

these

fields

are

just

left

undefined

Delegating

adds

the

constant

time

of

logging

the

delegation

operation

and

updating

the

Ob

Lists

of

the

delegator

and

delegatee

transactions

by

moving

as

many

scopes

as

objects

are

delegated

-LRB-

hence

the

linearity

-RRB-

This

entails

lookup/updates

to

the

transactions

Ob

List

which

resides

in

main

memory

and

can

be

organized

for

efficient

lookup/update

At

transaction

termination

the

Ob

List

can

be

simply

discarded

As

for

recovery

ARIES/RH

's

forward

pass

incurs

the

same

overhead

as

ARIES

does

to

reconstruct

transactional

data

structures

and

redo

updates

Again

the

only

additional

information

that

is

collected

is

piggy-backed

in

those

data

structures

No

special

sweep

of

the

log

is

required

ARIES/RH

obtains

its

information

during

the

same

accesses

as

the

conventional

algorithm

Specifically

the

forward

pass

of

recovery

is

only

different

from

that

of

ARIES

in

its

processing

of

update

-LRB-

there

is

an

extra

check

for

ob

Ob

List

-LRB-

t

-RRB-

-RRB-

and

delegate

-LRB-

same

check

and

the

move

from

one

Ob

List

to

the

other

-RRB-

Thus

ARIES/RH

adds

neither

extra

log

sweeps

nor

costs

proportional

to

the

length

of

the

log

as

it

uses

the

same

sweeps

of

the

log

as

ARIES

to

reconstruct

the

delegation

information

We

expect

the

Ob

List

to

be

much

smaller

than

the

log

being

analyzed

and

to

wholly

reside

in

main

memory

Thus

the

cost

of

accessing

Ob

List

is

small

compared

to

bringing

the

log

from

stable

storage

the

dominant

cost

during

recovery

The

backward

pass

of

recovery

reads

the

log

in

much

the

same

way

as

ARIES

by

continually

taking

the

maximum

Log

Sequence

Number

that

must

be

undone

-LRB-

in

ARIES

-RRB-

or

the

scope

clusters

within

which

updates

must

be

undone

-LRB-

in

ARIES/RH

-RRB-

In

ARIES/RH

we

examine

log

records

in

clusters

formed

by

loser

scopes

but

as

in

ARIES

we

do

it

in

a

monotonically

decreasing

way

To

compare

with

ARIES

we

need

only

examine

the

costs

for

processing

update

records

-LRB-

the

rest

are

just

as

in

ARIES

-RRB-

For

each

update

we

do

a

lookup

in

Cluster

for

a

check

of

delegation

scope

-LRB-

to

decide

whether

to

undo

it

-RRB-

and

possibly

write

a

Compensation

Log

Record

Otherwise

we

just

add

or

remove

scopes

from

the

Cluster

and

the

LsrScopes

sets

In

summary

the

ARIES/RH

algorithm

adds

only

minimal

overhead

to

support

delegation

Related

Work

We

have

benefited

from

insights

gained

in

an

effort

with

goals

closer

to

ours

the

work

at

GTE

Labs

on

Transaction

Specification

and

Management

Environment

-LRB-

TSME

-LSB-

-RSB-

-RRB-

The

architecture

of

TSME

consists

of

a

Transaction

Specification

Facility

that

understands

TSME

's

transaction

specification

language

and

drives

the

Transaction

Management

Mechanism

which

configures

the

run-time

system

to

support

a

specific

Extended

Transaction

Model

The

Transaction

Management

Mechanism

is

programmable

but

uses

templates

to

describe

existing

extended

transaction

models

and

also

to

drive

the

incorporation

of

only

the

components

necessary

for

a

given

Extended

Transaction

Model

It

is

a

toolkit

approach

in

which

certain

expressions

in

the

specification

language

are

mapped

to

certain

configurations

of

pre-built

components

so

it

approaches

the

problem

at

a

coarser

grain

This

may

allow

for

initial

gains

in

performance

but

we

believe

that

the

use

of

language

primitives

is

a

richer

and

more

flexible

approach

The

recent

work

of

Barga

and

Pu

-LSB-

-RSB-

also

inspired

in

part

by

ACTA

explores

another

modular

approach

based

on

the

ideas

of

metaobject

protocols

-LSB-

-RSB-

and

incorporates

some

elements

of

the

TSME

approach

and

some

of

our

language-based

approach

Also

related

is

the

work

on

the

ConTract

model

-LSB-

-RSB-

In

ConTract

a

set

of

steps

define

individual

transactions

a

script

is

provided

to

control

the

execution

of

these

transactions

But

ConTract

scripts

introduce

their

own

control

flow

syntax

while

ASSET

introduces

a

small

set

of

transaction

management

primitives

that

can

be

embedded

in

a

host

language

Other

related

work

also

includes

Structured

Transaction

Definition

Language

-LSB-

-RSB-

a

persistent

programming

language

geared

to

portability

and

the

integration

of

legacy

applications

Its

emphasis

however

is

in

Application

Programming

Interfaces

conforming

to

existing

conventional

transactional

technology

Finally

the

idea

of

rewriting

history

is

a

natural

extension

of

the

repeating

history

paradigm

of

ARIES

-LSB-

-RSB-

and

is

a

generalization

of

ARIES/NT

-LSB-

-RSB-

an

extension

to

ARIES

for

nested

transactions

-LSB-

-RSB-

Conclusions

Recent

work

has

produced

many

Extended

Transaction

Models

-LRB-

ETMs

-RRB-

but

each

has

its

own

tailor-made

implementation

With

delegation

-LRB-

and

the

other

two

ASSET

primitives

permit

and

form-dependency

-LSB-

-RSB-

-RRB-

we

believe

we

can

offer

the

flexibility

to

synthesize

a

wide

range

of

ETMs

at

a

performance

comparable

to

that

of

tailor-made

implementations

Delegation

by

allowing

changes

in

the

visibility

and

recovery

properties

of

transactions

is

a

very

useful

primitive

for

synthesizing

Extended

Transaction

Models

Our

work

builds

on

the

formal

foundation

provided

by

ACTA

-LSB-

-RSB-

and

the

primitives

introduced

in

ASSET

-LSB-

-RSB-

The

main

contribution

of

this

paper

is

the

concept

of

rewriting

history

-LRB-

RH

-RRB-

designed

to

achieve

the

semantics

of

delegation

in

an

efficient

and

robust

manner

We

believe

that

this

work

forms

a

crucial

step

towards

the

flexible

synthesis

of

ETMs

ffl

By

casting

delegation

in

terms

of

rewriting

history

we

were

able

to

express

the

issues

of

delegation

in

terms

amenable

to

the

specification

of

a

recovery

algorithm

ffl

We

showed

how

to

achieve

RH

in

the

context

of

a

practical

system

-LRB-

ARIES

-RRB-

and

sketched

how

to

apply

it

to

another

-LRB-

EOS

-RRB-

suggesting

the

practical

implementability

of

delegation

As

indicated

in

section

the

cost

of

delegation

in

ARIES/RH

is

very

low

and

its

support

incurs

no

cost

at

all

when

delegation

is

not

being

used

ffl

We

have

also

demonstrated

the

correctness

of

our

implementation

showing

that

it

satisfies

the

desired

transaction

properties

in

the

presence

of

delegation

We

are

currently

implementing

RH

within

EOS

We

will

continue

investigating

the

broader

issues

of

providing

robust

efficient

and

flexible

transaction

processing

In

particular

we

are

interested

in

making

recovery

a

first-class

concept

within

transaction

management

and

in

pro-

viding

a

variety

of

recovery

primitives

to

a

transaction

programmer

so

that

different

recovery

requirements

and

recovery

semantics

can

be

achieved

flexibly

Acknowledgments

We

thank

Lory

Molesky

Jagan

Peri

and

Jayavel

Shanmugasundaram

for

valuable

discussions

We

also

thank

Mohan

Kamath

and

Amer

Diwan

whose

comments

helped

make

this

paper

more

readable

References

-LSB-

-RSB-

Roger

S.

Barga

and

Calton

Pu

A

Practical

and

Modular

Implementation

of

Extended

Transaction

Models

In

Proceedings

of

the

International

Conference

on

Very

Large

Data

Bases

September

-LSB-

-RSB-

Philip

A.

Bernstein

Vassos

Hadzilacos

and

Nathan

Goodman

Concurrency

Control

and

Recovery

in

Database

Systems

Addison

Wesley

Reading

Mass.

-LSB-

-RSB-

Philip

A.

Bernstein

Per

O.

Gyllstrom

and

Tom

Wimberg

STDL

-LCB-

A

Portable

Language

for

Transaction

Processing

In

Proceedings

of

the

International

Conference

on

Very

Large

Databases

pages

-LCB-

Dublin

-LSB-

-RSB-

A.

Biliris

E.

Panagos

EOS

User

's

Guide

AT&T

Bell

Labs

Report

May

-LSB-

-RSB-

A.

Biliris

S.

Dar

N.

Gehani

H.

V.

Jagadish

K.

Ramamritham

ASSET

A

System

for

Supporting

Extended

Transactions

In

Proceedings

of

the

ACM

SIGMOD

International

Conference

on

Management

of

Data

Minneapolis

Minn.

June

-LSB-

-RSB-

P.

K.

Chrysantis

and

Krithi

Ramamritham

Synthesis

of

Extended

Transaction

Models

using

ACTA

ACM

Trans

on

Database

Systems

September

-LSB-

-RSB-

P.

K.

Chrysanthis

ACTA

A

Framework

for

Modeling

and

Reasoning

about

Extended

Transactions

Computer

Science

TR

PhD

thesis

Department

of

Computer

and

Information

Science

University

of

Massachusetts

Amherst

Mass.

September

-LSB-

-RSB-

P.

K.

Chrysantis

and

Krithi

Ramamritham

Delegation

in

ACTA

as

a

Means

to

Control

Sharing

in

Extended

Transactions

IEEE

Data

Engineering

-LRB-

-RRB-

June

-LSB-

-RSB-

D.

Georgakopoulos

M.

Hornick

P.

Krychniak

and

F.

Manola

Specification

and

Management

of

Extended

Transactions

in

a

Programmable

Transaction

Environment

In

Proceedings

of

International

Conference

on

Data

Engineering

Houston

Tex.

February

-LSB-

-RSB-

A.

K.

Elmagarmid

editor

Database

Transaction

Models

for

Advanced

Applications

Morgan

Kaufman

-LSB-

-RSB-

Narain

Gehani

Krithi

Ramamritham

Oded

Shmueli

Accessing

Extra

Database

Information

Concurrency

Control

and

Correctness

Computer

Science

TR

University

of

Massachusetts

Amherst

-LSB-

-RSB-

Jim

Gray

and

Andreas

Reuter

Transaction

Processing

Concepts

and

Techniques

Morgan

Kaufman

San

Jos?e

Calif.

-LSB-

-RSB-

Gregor

Kiczales

Jim

des

Rivi?eres

Daniel

G.

Bobrow

The

Art

of

the

Metaobject

Protocol

MIT

Press

Cambridge

Mass.

-LSB-

-RSB-

C.

Mohan

D.

Haderle

B.

Lindsay

H.

Pirahesh

P.

Schwartz

ARIES

A

Transaction

Recovery

Method

Supporting

Fine-Granularity

Locking

and

Partial

Rollbacks

Using

Write-Ahead

Logging

In

ACM

TODS

-LRB-

-RRB-

-LCB-

-LSB-

-RSB-

J.

Eliot

B.

Moss

Nested

Transactions

An

approach

to

reliable

distributed

computing

PhD

thesis

Massachusetts

Institute

of

Technology

Cambridge

Mass.

April

-LSB-

-RSB-

C.

Pu

G.

Kaiser

G.

and

N.

Hutchinson

Split-Transactions

for

Open-Ended

Activities

In

Proceedings

of

the

International

Conference

on

Very

Large

Data

Bases

pages

-LCB-

Los

Angeles

CA

Sept.

-LSB-

-RSB-

Cris

Pedregal

Martin

and

Krithi

Ramamritham

ARIES/RH

Robust

Support

for

Delegation

by

Rewriting

History

TR

Computer

Science

Dept.

University

of

Massachusetts

Amherst

June

-LSB-

-RSB-

Cris

Pedregal

Martin

and

Krithi

Ramamritham

Delegation

Efficiently

Rewriting

History

TR

Computer

Science

Dept.

University

of

Massachusetts

Amherst

October

-LSB-

-RSB-

Rothermel

K.

and

C.

Mohan

ARIES/NT

A

Recovery

Method

Based

on

Write-Ahead

Logging

for

Nested

Transactions

In

Proceedings

of

the

International

Conference

on

Very

Large

Databases

pages

-LCB-

Amsterdam

-LSB-

-RSB-

H.

W?achter

and

A.

Reuter

The

ConTract

Model

In

-LSB-

-RSB-

-LSB-

-RSB-

Gerhard

Weikum

Christof

Hasse

Peter

Broessler

Peter

Muth

Multi-Level

Recovery

In

ACM

International

Symposium

on

Principles

of

Database

Systems

pages

-LCB-

Nashville

extended transaction models
recovery
transaction management