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#>
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#>
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:
This means that the state of the system at each end must be
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:
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:
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.
All of these functions require stable storage (i.e. disk/battery backed RAM
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.
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
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.