Transactions:Implementation of Isolation

By -

Implementation of Isolation

So far, we have seen what properties a schedule must have if it is to leave the database in a consistent state and allow transaction failures to be handled in a safe manner. Specifically, schedules that are conflict or view serializable and cascadeless satisfy these requirements.

There are various concurrency-control schemes that we can use to ensure that,

even when multiple transactions are executed concurrently, only acceptable schedules are generated, regardless of how the operating-system time-shares resources (such as CPU time) among the transactions.

As a trivial example of a concurrency-control scheme, consider this scheme: A transaction acquires a lock on the entire database before it starts and releases the lock after it has committed. While a transaction holds a lock, no other transaction is allowed to acquire the lock, and all must therefore wait for the lock to be released. As a result of the locking policy, only one transaction can execute at a time. Therefore, only serial schedules are generated. These are trivially serializable, and it is easy to verify that they are cascadeless as well.

A concurrency-control scheme such as this one leads to poor performance, since it forces transactions to wait for preceding transactions to finish before they can start. In other words, it provides a poor degree of concurrency. As explained in Section 15.4, concurrent execution has several performance benefits.

The goal of concurrency-control schemes is to provide a high degree of concurrency, while ensuring that all schedules that can be generated are conflict or view serializable, and are cascadeless.

We study a number of concurrency-control schemes in Chapter 16. The schemes have different trade-offs in terms of the amount of concurrency they allow and the amount of overhead that they incur. Some of them allow only conflict serializable schedules to be generated; others allow certain view-serializable schedules that are not conflict-serializable to be generated.

Transaction Definition in SQL

A data-manipulation language must include a construct for specifying the set of actions that constitute a transaction.

The SQL standard specifies that a transaction begins implicitly. Transactions are ended by one of these SQL statements:

• Commit work commits the current transaction and begins a new one.

• Rollback work causes the current transaction to abort.

The keyword work is optional in both the statements. If a program terminates with- out either of these commands, the updates are either committed or rolled back — which of the two happens is not specified by the standard and depends on the implementation.

The standard also specifies that the system must ensure both serializability and freedom from cascading rollback. The definition of serializability used by the standard is that a schedule must have the same effect as would some serial schedule. Thus, conflict and view serializability are both acceptable.

The SQL-92 standard also allows a transaction to specify that it may be executed in a manner that causes it to become nonserializable with respect to other transactions.

We study such weaker levels of consistency in Section 16.8.

Comments

Post a Comment

Popular posts from this blog

XML Document Schema

By -
Image
XML Document Schema Databases have schemas, which are used to constrain what information can be stored in the database and to constrain the data types of the stored information. In contrast, by default, XML documents can be created without any associated schema: An el- ement may then have any subelement or attribute. While such freedom may occasionally be acceptable given the self-describing nature of the data format, it is not generally useful when XML documents must be processesed automatically as part of an application, or even when large amounts of related data are to be formatted in XML. Here, we describe the document-oriented schema mechanism included as part of the XML standard, the Document Type Definition , as well as the more recently defined XML S chema . Document Type Definition The document type definition ( D TD ) is an optional part of an XML document. The main purpose of a DTD is much like that of a schema: to constrain and type the information present in the docume
Read more

Extended Relational-Algebra Operations.

By -
Image
Extended Relational-Algebra Operations The basic relational-algebra operations have been extended in several ways. A simple extension is to allow arithmetic operations as part of projection. An important extension is to allow aggregate operations such as computing the sum of the elements of a set, or their average. Another important extension is the outer-join operation, which allows relational-algebra expressions to deal with null values, which model missing information. Generalized Projection The generalized-projectio n operation extends the projection operation by allowing arithmetic functions to be used in the projection list. The generalized projection operation has the form where E is any relational-algebra expression, and each of F 1 , F 2 ,.. . , F n is an arithmetic expression involving constants and attributes in the schema of E . As a special case, the arithmetic expression may be simply an attribute or a constant. For example, suppose we have a relation c r
Read more

Distributed Databases:Concurrency Control in Distributed Databases

By -
Image
Concurrency Control in Distributed Databases We show here how some of the concurrency-control schemes discussed in Chapter 16 can be modified so that they can be used in a distributed environment. We assume that each site participates in the execution of a commit protocol to ensure global trans- action atomicity. The protocols we describe in this section require updates to be done on all replicas of a data item. If any site containing a replica of a data item has failed, updates to the data item cannot be processed. In Section 19.6 we describe protocols that can continue transaction processing even if some sites or links have failed, thereby providing high availability. Locking Protocols The various locking protocols described in Chapter 16 can be used in a distributed environment. The only change that needs to be incorporated is in the way the lock manager deals with replicated data. We present several possible schemes that are applicable to an environment where data can be rep
Read more