Concurrency Control and Recovery in Database Systems |
|||
|
ISBN : O201107155 |
|||
![]() Cover Design - Concurrency Control and Recovery in Database Systems |
For your free electronic copy of this book please verify the numbers below. (We need to do this to make sure you're a person and not a malicious script) | ||
|
Sample Chapter From Concurrency Control and Recovery in Database Systems Copyright © Philip A. Bernstein, Vassos Hadzilacos, Nathan Goodman |
|||
1 .l TRANSACTIONSConcurrency 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 hardware 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 database 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 transaction 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. 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 transaction 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 SystemsA 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, typically X, y, and Z.A database system (DSS)’ is a collection of hardware and software modules that support commands to access the database, called database operations (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.
|
|||