ConcurrencyControlandRecoveryinDatabaseSystems资源-CSDN文库

chapter

需积分: 2 89 浏览量 2009-05-21 22:17:47 上传评论收藏 1.61MB PDF 举报

资源推荐

资源详情

资源评论

THE PROBLEM

1 .l TRANSACTIONS

Concurrency control is the activity of coordinating the actions of processes

that operate in parallel, access shared data, and therefore potentially interfere

with each other. Recovery is the activity of ensuring that software and hard-

ware failures do not corrupt persistent data. Concurrency control and recovery

problems arise in the design of hardware, operating systems, real time systems,

communications systems, and database systems, among others. In this book,

we will explore concurrency control and recovery problems in database

systems.

We will study these problems using a model of database systems. This

model is an abstraction of many types of data handling systems, such as data-

base management systems for data processing applications, transaction

processing systems for airline reservations or banking, and file systems for a

general purpose computing environment. Our study of concurrency control

and recovery applies to any such system that conforms to our model.

The main component of this model is the transaction. Informally, a trans-

action is an execution of a program that accesses a shared database. The goal

of concurrency control and recovery is to ensure that transactions execute

atomically, meaning that

1. each transaction accesses shared data without interfering with other

transactions, and

2. if a transaction terminates normally, then ail of its effects are made

permanent; otherwise it has no effect at all.

The purpose of this chapter is to make this model precise.

Contents

Index

2 CHAPTER 1 / THE PROBLEM

In this section we present a user-oriented model of the system, which

consists of a database that a user can access by executing transactions. In

Section

1.2,

we explain what it means for a transaction to execute atomically

in the presence of failures. In Section 1.3, we explain what it means for a trans-

action to execute atomically in an environment where its database accesses can

be interleaved with those of other transactions. Section 1.4 presents a model of

a database system’s concurrency control and recovery components, whose goal

is to realize transaction atomicity.

Database Systems

A database consists of a set of named data items. Each data item has a value.

The values of the data items at any one time comprise the state of the database.

In practice, a data item could be a word of main memory, a page of a disk,

a record of a file, or a field of a record. The size of the data contained in a data

item is called the gratzularity of the data item. Granularity will usually be

unimportant to our study and we will therefore leave it unspecified. When we

leave granularity unspecified, we denote data items by lower case letters, typi-

cally X, y, and Z.

A database s~istenz (DSS)’ is a collection of hardware and software

modules that support commands to access the database, called database opera-

tions (or simply operations). The most important operations we will consider

are Read and Write. Read(x) returns the value stored in data item X. Write(x,

val) changes the value of x to val. We will also use other operations from time

to time.

The DBS executes each operation atomically. This means that the DBS

behaves as if it executes operations sequentially, that is, one at a time. To

obtain this behavior, the DBS might actual/y execute operations sequentially.

However, more typically it will execute operations concurrently That is, there

tnay be rimes when it is executing more than one operation at once. However,

even if it executes operations concurrently, the final effect must be the same as

some sequential execution.

For example, suppose data items x and 4’ are stored on two different

devices. The DBS might execute operations on x and y in this order:

execute Read(x);

2. after step (I) is finished, concurrently execute Write(x, 1) and Read(y);

3. after step (2) is finished, execute Write(y, 0).

AIthough Write(x, 1) and Read(y) were executed concurrently, they may

be regarded as having executed atomically. This is because the execution just

‘We use rhe abbreviation

DBS,

instead of the more conventional

DBhfS,

to emphasize thar a

DBS in our sense maI- be much less than an integrated database management system. For exam-

ple, it may only be a simple file system with transaction management capabllities.

1.1 TRANSACTIONS 3

given has the same effect as a sequential execution, such as Read(x), Write(x,

l), Read(y), Write(y, 0).

The DBS also supports transaction operations: Start, Commit, and Abort.

program tells the DBS that it is about to begin executing a new transaction

by issuing the operation Start. It indicates the termination of the transaction by

issuing either the operation Commit or the operation Abort. By issuing a

Commit, the program tells the DBS that the transaction has terminated

normally and all of its effects should be made permanent. By issuing an Abort,

the program tells the DBS that the transaction has terminated abnormally and

all of its effects should be obliterated.

A program must issue each of its database operations on behalf of a partic-

ular transaction. We can model this by assuming that the DBS responds to a

Start operation by returning a unique transaction identifier. The program then

attaches this identifier to each of its database operations, and to the Commit or

Abort that it issues to terminate the transaction. Thus, from the DBS’s view-

point, a transaction is defined by a Start operation, followed by a (possibly

concurrent) execution of a set of database operations, followed by a Commit

or Abort.

A transaction may be a concurrent execution of two or more programs.

That is, the transaction may submit two operations to the DBS before the DBS

has responded to either one. However, the transaction’s last operation must be

a Commit or Abort. Thus, the DBS must refuse to process a transaction’s data-

base operation if it arrives after the DBS has already executed the transaction’s

Commit or Abort.

Transaction Syntax

Users interact with a DBS by invoking programs. From the user’s viewpoint, a

transaction is the execution of one or more programs that include database

and transaction operations.

For example, consider a banking database that contains a file of customer

accounts, called Accounts, each entry of which contains the balance in one

account. A useful transaction for this database is one that transfers money

from one account to another.

Procedure Transfer

begin

Start;

input(fromaccount, toaccount, amount);

/’ This procedure transfers “amount” from “fromaccount” into “toaccount.’ ”

temp : =

Read(Accounts[fromaccount]);

if temp < amount

then begin

output( “insufficient funds”);

Abort

end

4 CHAPTER 1 I THE PROBLEM

else begin

Write(Accounts[fromaccount], temp - amount);

temp

: = Read(Accounts[toaccount]);

WritefAccounts[toaccount], temp + amount);

Commit;

output( “transfer completed”);

end;

return

end

“Transfer’! illustrates the programming language we will use in examples.

It includes the usual procedure declaration (Procedure procedure-name begin

procedure-body end), assignment statement (variable : = expression), a condi-

tional statement (if Boolean-expression then statement else statement), input

(which reads a list of vaIues from a terminal or other input device and assigns

them to variables), output (which lists values of constants or variables on a

terminal or other output device), begin-end brackets to treat a statement list as

a single statement (begin statement-list end), a statement to return from a

procedure (return), and brackets to treat text as a comment (/ * comment * /).

We use semicolons as statement separators, in the style of Algol and Pascal.

The choice of language for expressing transactions is not important to our

study of concurrency control and recovery. In practice, the language could be a

database query language, a report writing language, or a high level program-

ming language augmented with database operations. No matter how the trans-

action is expressed, it must eventualIy be translated into programs that issue

database operations, since database operations are the only way to access the

database. We therefore assume that the programs that comprise transactions

are written in a high level language with embedded database operations.

Transfer is an unrealistic program in that it doesn’t perform any error

checking, such as testing for incorrect input. Although such error checking is

essential if application programs are to be reliable, it is unimportant to our

understanding of concurrency control and recovery probIems. Therefore, to

keep our example programs short, we will ignore error checking in those

programs.

Commit and Abort

After the DBS executes a transaction’s Commit (or Abort) operation, the trans-

action is said to be committed (or aborted). A transaction that has issued its

Start operation but is not yet committed or aborted is called active. A transac-

tion is uncommitted if it is aborted or active.

A transaction issues an Abort operation if it cannot be completed correctly,

The transaction itself may issue the Abort because it has detected an error from

which it cannot recover, such as the “insufficient funds” condition in Transfer.

剩余23页未读，继续阅读

评论收藏

内容反馈

laurie1118

粉丝: 0
资源: 9

Concurrency Control and Recovery in Database Systems

最新资源

Concurrency Control and Recovery in Database Systems

concurrency control in advanced database application

Concurrency Control and Recovery in Database Systems全本.pdf

数据库系统中的并发控制和恢复Concurrency Control And Recovery in Database Systems

Concurrency Control and Recovery in Database Systems-Ch7.pdf

Main Memory Database Systems

Microsoft SQL Server 2016: A Beginner’s Guide, 6th Edition

database management systems solutions manual third edition

Database Management Systems 3rd Edition - Solutions

Database_Tuning___Principles_Experiments_and_Troubleshooting_Techniques(unsecured)

Advanced SQL Programming

java 数据挖掘，pdf，2006

实时数据库系统（RTDBS）及其特征

数据库系统概念第七版答案

Qt 5实现串口调试助手 （源工程文件、0积分下载）

【SystemVerilog】路科验证V2学习笔记（全600页）.pdf

AutoSAR标准协议4.2.2

光伏-储能并网系统仿真.rar

XCP协议的规范文档

GD32替换STM32注意事项.pdf

NPPJSONViewer.zip

蓝牙BLE协议中文版.pdf

CANoe通过CAPL脚本实现自动测试

AD20官方中文教程.pdf

完整版 Microsoft.ACE.OLEDB.12.0 驱动下载.rar

电路分析基础第二版PDF电子书免费下载

Tangent免费.rar

最新资源

Qt 5实现串口调试助手（源工程文件、0积分下载）