Sagas长时间的事务的实现，跨越多个区域的分布式事务的处理机制.pdf

Oracle6

11页

0次

2023-04-23

免费下载

SAGAS

Hector Garcaa-Molrna

Kenneth Salem

Department of Computer Science

Princeton University

Princeton, N J 08544

Abstract

Long lived transactions (LLTs) hold on to

database resources for relatively long periods of

time, slgmficantly delaymg the termmatlon of

shorter and more common transactions To

alleviate these problems we propose the notion of

a saga A LLT 1s a saga if it can be written as a

sequence of transactions that can be interleaved

with other transactions The database manage-

ment system guarantees that either all the tran-

sactions m a saga are successfully completed or

compensatmg transactions are run to amend a

partial execution Both the concept of saga and

its lmplementatlon are relatively simple, but they

have the potential to improve performance

slgmficantly We analyze the various lmplemen-

tatron issues related to sagas, including how they

can be run on an exlstmg system that does not

directly support them We also discuss tech-

niques for database and LLT design that make it

feasible to break up LLTs mto sagas

1. INTRODUCTION

As its name indicates, a long lived transac-

tron 1s a transactlon whose execution, even

without interference from other transactions,

takes a substantial amount of time, possibly on

the order of hours or days

A long lived transac-

tion, or LLT, has a long duration compared to

Permlsslon to copy wlthout fee all or part of this material IS granted

provided that the copies are not made or dlstrlbuted for direct

commercial advantage, the ACM copyrlght notice and the title of

the pubhcatlon and Its date appear, and notlce IS given that copymg

IS by permlsslon of the Assoclatlon for Computmg Machmery To

copy otherwlse, or to repubhsh, requires a fee and/or specfic

permisslon

0 1987 ACM O-89791-236-5/87/0005/0249 75@

the malorlty of other transactions either because

it accesses many database obJects, it has lengthy

computations, it pauses for inputs from the users,

or a combmatlon of these factors Examples of

LLTs are transactions to produce monthly

account statements at a bank, transactions to

process claims at an insurance company, and

transactions to collect statrstlcs over an entire

database [Graysla]

In most cases, LLTs present serious perfor-

mance problems Since they are transactions, the

system must execute them as atomic actions, thus

preserving the consistency of the

database [DateSla,Ullm82a] To make a tran-

saction atonuc, the system usually locks the

objects accessed by the transaction until It com-

mits, and this typically occurs at the end of the

transactlon

As a consequence, other transac-

tions wishing to access the LLT’s objects suffer a

long locking delay

If LLTs are long because they

access many database obJects then other transac-

tions are likely to suffer from an mcreased block-

mg rate as well, 1 e they are more likely to

conflict with an LLT than with a shorter transac-

tion

Furthermore, the transaction abort rate can

also be increased by LLTs As discussed

m [Gray8lb], the frequency of deadlock 1s very

sensitive to the “size” of transactions, that IS, to

how many oblects transactions access (In the

analysis of [GraySlb] the deadlock frequency

grows with the fourth power of the transaction

size ) Hence, since LLTs access many oblects,

they may cause many deadlocks, and correspond-

ingly, many abortions

From the point of view of

system crashes, LLTs have a higher probability of

encountering a failure (because of their duration),

and are thus more likely to encounter yet more

delays and more likely to be aborted themselves

249

In general there 1s no solution that ehm-

mates the problems of LLTs Even d we use a

mechanism different from locking to ensure atom-

lclty of the LLTs, the long delays and/or the high

abort rate ~111 remam No matter how the

mechanism operates, a transactlon that needs to

access the objects that were accessed by a LLT

cannot commit until the LLT commits

However, for specific applreatsons lt may be

possible to alleviate the problems by relaxing the

requirement that an LLT be executed as an

atormc actlon

In other words, without sacrlficmg

the consistency of the database, it may be possl-

ble for certain LLTs to release their resources

before they complete, thus permitting other walt-

mg transactions to proceed

To illustrate this idea, consider an alrhne

reservation apphcatlon The database (or actu-

ally a collection of databases from different air-

lines) contams reservations for flights, and a tran-

saction

wishes to make a number of reserva-

tions, For this dlscusslon, let us assume that

T IS

a LLT (say It pauses for customer input after

each reservation) In this apphcatlon It may not

be necessary for

to hold on to all of its

resources until it completes For instance, after

reserves a seat on flight Fl, it could lmmedl-

ately allow other transactions to reserve seats on

the same flight In other words, we can view

as a collection of “sub-transactions”

T1, Tz,

T,,

that reserve the mdlvldual seats

However, we do not wish to submit

to the

database management system (DBMS) simply as

a collection of independent transactions because

we still want

to be a unit that IS either suc-

cessfully completed or not done at all

We would

not be satisfied with a DBMS that would allow

to reserve three out of five seats and then (due to

a crash) do nothmg more

On the other hand, we

would be satisfied with a DBMS that guaranteed

that

would make all of its reservations, or

would cancel any reservations made If

had to

be suspended

This example shows that a control mechan-

ism that 1s less rlgld than the conventional

atomic-transaction ones but still offers some

guarantees regardmg the execution of the com-

ponents of an LLT would be useful

In this paper

we will present such a mechamsm

Let us use the term eaga to refer to a LLT

that can be broken up mto a collection of sub-

transactions that can be mterleaved m any way

with other transactlons Each sub-transactlon m

this case 1s a real transaction m the sense that it,

preserves database consistency However, unlike

other transactions, the transactions m a saga are

related to each other and should be executed as a

(non-atomic) unit any partial executions of the

saga are undesirable, and if they occur, must be

compensated for

To amend partial executions, each saga

transaction

should be provided with a com-

pensating transaction C, The compensatmg

transaction undoes, from a semantic point of

view, any of the actions performed by

T,,

but

does not necessarily return the database to the

state that existed when the execution of

began In our airline example, if

reserves a

seat on a flight, then C, can cancel the resewa-

tlon (say by subtracting one from the number of

reservations and performing some other checks)

But C, cannot simply store m the database the

number of seats that existed when

ran because

other transactions could have run between the

time

reserved the seat and C, canceled the

reservation, and could have changed the number

of reservations for this flight

Once compensating transactions Cl, Cs,

n-1 are defined for saga

T1, Tz, T,,,

then

the system can make the followmg guarantee

Either the sequence

Tl,

T2,

T?8

(which 1s the preferable one) or the sequence

TI,

T29

T,, C,,

c2,

for some 0 < J < 12 ~111 be executed

(Note that

other transactions might see the effects of a par-

tial saga execution When a compensatmg tran-

saction C, 1s run, no effort 1s made to notify or

abort transactions that nught have seen the

results of

before they were compensated for by

c, 1

Sagas appear to be a relatively common

type of LLT

They occur when a LLT consists of

a sequence of relatively independent steps, where

each step does not have to observe the eame con-

sistent database state

For Instance, m a bank It

1s common to perform a fixed operation (e g ,

compute interest) on all accounts, and there 1s

very little interaction between the computations

for one account and the next In an office mfor-

matlon system, It IS also common to have LLTs

with independent steps that can be Interleaved

with those of other transactions For example,

receiving a purchase order mvolves entering the

250

of 11

免费下载

sagas长时间的事务的实现

关注

评论