Transactions

We have seen that concurrent access to a shared object by separate clients can lead to consistency problems. The mechanism that is employed to avoid these problems is <#614#> atomic<#614#> transactions. With knowledge that the service is shared, the client program may be written, specifying that some sequence of operations on the shared object are not to be interleaved with operations by other clients. Essentially, a group of operations are structured into a single <#615#> atomic<#615#> operation which is called a transaction. The four properties of an Atomic Operation are referred to conventionally the useful acronym ;SPM_quot;ACID;SPM_quot; - Atomicity, Consistency, Independence and Durability. A major consequence of transactions is the requirement for mechanisms for failure recovery. If the client or the server fail <#616#> during<#616#> a transaction, the transaction must appear to have either:

Completed Successfully
Failed Completely

This means that the state of the system at each end must be <#619#> recoverable<#619#>. The Transaction is a mechanism that was devised for database systems. Its purpose it to maximize <#620#> consistency<#620#> of stored data. This consistency must be maintained in the face of failures, and without placing unnecessary restrictions on any concurrency between different applications accessing the data. Its properties include:

A Transaction consists of an arbitrary sequence of operations, bracketed by a StartTransaction, and an EndTransaction.
The transaction is said to be <#622#> atomic<#622#> if:
- either all the operations succeed, and the overall transaction succeeds.
- none appear to succeed, and the transaction fails - <#624#> failure atomicity<#624#>.
If more than one transaction is executed concurrently, then the effect must be the same as if the separate transactions had been executed one at a time (but in no specific order). This property of concurrent transactions is known as <#626#> serial equivalence<#626#> (the transactions are <#627#> serializable<#627#>. This is achieved through use of some concurrency control mechanism such as locking, timestamp or optimistic concurrency control (see below).
If one of some concurrent transactions fails (does not complete), its results (intermediate or terminal) are not hidden from the other transactions.

Transaction services are sometimes offered on file systems as well as database systems. In an Open Distributed System, transactions are a way of offering this failure atomicity on any object in the system (ref Persistent Objects). To provide a transaction service, certain functions are required:

The transaction must be <#630#> recoverable<#630#>. Either the transaction can be reversed (the is an inverse operation, and the current operation is reliably logged), or else some previous version of the data/object is available.
When each operation is invoked after the transaction is started, it is logged or else the operation is made on a <#631#> tentative<#631#> version of the data.
When the client ends the transaction, if all the operations have succeeded, the server will return to the client that the transaction is <#632#> committed<#632#>.
If the client finds some fault or error, it may ABORT the transaction. This causes the server to wind back the state of the data as if no operation had been invoked.
If the server fails for some reason (lack of resources/error), it must wind back to the same previous state (this may be after a restart) and report to the client that the transaction has failed.

All of these functions require stable storage (i.e. disk/battery backed RAM etc). Transactions are another tool to make programming distributed applications easier. The Atomicity property means that the programmer does not have to concern himself with consistency. They can group operations in a transaction arbitrarily, without concern for what failures may occur in the client, server or network. They are guaranteed that the stable storage holding the data will either contain successful results, or no change. The serializability of concurrent transactions means that each application programmer is sealed off from others. They need not concern themselves with the ORDER in which operations are invoked in different applications. Applications are shielded from handling errors caused by other applications by the way transactions hide tentative intermediate updates.