TRANSACTIONS & CONCURRENCY CONTROL (Single SERVER) Ch 16 (5th Ed) 16.1 Introduction 16.2 Transaction 16.2.

1 Concurrency Control
10-6-2012

16.1 Introduction
Recoverable Objects: Objects that can be recovered after their server crashes are called recoverable objects. Where SERVER stores Objects: The objects managed by a server may be stored in: 1- Volatile memory (for example, RAM) or 2- Persistent memory (for example, a hard disk). Even if objects are stored in volatile memory, the server may use persistent memory to store sufficient information for the state of the objects to be recovered if the server process crashes. This enables servers to make objects recoverable. What is a transaction? A transaction is specified by a client as:

- a set of operations on objects to be performed as an indivisible unit by the servers managing those objects. - IS a sequence of Operations that perform single step. IF: A= 100, B= 200, C= 300 Transaction T: a.withdraw (100); b.deposite (100); c.withdraw (200); b.deposite(200); Execute T, Then A,B,C ? Mechanism: Transaction achieved by: 1. Client program 2. Recoverable object 3. Coordinator The servers must guarantee that: 1- Either the entire transaction is carried out and the results recorded in permanent storage or, 2- In the case that one or more of them crashes, its effects are completely erased. The goal: The goal of transactions is to ensure that all of the objects managed by a server remain in a consistent state when they are accessed by multiple transactions and in the presence of server crashes. Transactions deal with:

1- Crash failures of processes and 2- Omission failures in communication, 3- But not any type of arbitrary (or Byzantine) behaviour. A clients transaction is also regarded as indivisible from the point of view of other clients transactions in the sense that the operations of one transaction cannot observe the partial effects of the operations of another.

ACID
1- ALL OR NOTHING RULE? - Atomicity (all or nothing ) - Durability (Permanent storage ) 2- ISOLATION :without interference 3- CONSISTENCY : C.state TO C.state , C:client Transaction END 1- Successful (closedTransaction) 2- Abort (Client (abortTransaction)or Server(Error) )

Processes and threads The traditional operating system notion of a process that executes a single activity was found in the 1980s to be unequal to the requirements of distributed systems require internal concurrency. The problem, is that the traditional process makes sharing between related activities awkward and expensive.

The solution reached was to enhance the notion of a process so that it could be associated with multiple activities. Process : Nowadays, a process consists of an execution environment together with one or more threads. A Thread: A thread is the operating system abstraction of an activity (the term derives from the phrase thread of execution). Threads can be created and destroyed dynamically, as needed. The central aim of having multiple threads of execution is: to maximize the degree of concurrent execution between operations, thus enabling the overlap of computation with input and output, and enabling concurrent processing on multiprocessors. This can be particularly helpful within servers, where concurrent processing of clients requests can reduce the tendency for servers to become bottlenecks. For example: one thread can process a clients request while a second thread servicing another request waits for a disk access to complete. As many older operating systems allow only one thread per process, we shall sometimes use the term multi-threaded process for emphasis. Confusingly, in some programming models and operating system designs the term process means what we have called a thread.

-Java wait and notify? An Execution Environment: An execution environment is the unit of resource management: a collection of local kernel managed resources to which its threads have access. An execution environment primarily consists of: an address space; thread synchronization and communication resources such as semaphores and communication interfaces (for example, sockets); higher-level resources such as open files and windows. Execution environments are normally expensive to create and manage, but several threads can share them that is, they can share all resources accessible within them. In other words, an execution environment represents the protection domain in which its threads execute. - An execution environment provides protection from threads outside it, so that the data and other resources contained in it are by default inaccessible to threads residing in other execution environments. - But certain kernels allow the controlled sharing of resources such as physical memory between execution environments residing at the same computer. - In the literature the terms heavyweight process, where an execution environment is taken to be included, and lightweight process, where it is not.
12-6-2012

16.2.1 Concurrency control

The Problems: Two well-known problems of concurrent transactions in the context of the banking example 1. The lost update problem and 2. The inconsistent retrievals problem. The Solution: Both of these problems can be avoided by using serially equivalent executions of transactions. We assume throughout that each of the operations deposit, withdraw, getBalance and setBalance is a synchronized operation that is, that its effects on the instance variable that records the balance of an account are atomic. The lost update problem The lost update problem is illustrated by the following pair of transactions on bank accounts Given: A=100, B= 200 ,C= 300. - Transaction T : transfers from A to B. - Transaction U : transfers from C to B. - In both cases, the a mount transferred is calculated to increase the balance of B by 10%. - The net effects on account B of executing the transactions T and U should be to increase the balance of account B by 10% twice, so its final value is $242.

- Now consider the effects of allowing the transactions T and U to run concurrently, as in Figure 1. - Both transactions get the balance of B as $200 and then deposit $20.

Figure 1 The result is incorrect, increasing the balance of account B by $20 instead of $42. This is an illustration of the lost update problem. Us update is lost because T overwrites it without seeing it. Both transactions have read the old value before either writes the new value.

Inconsistent Retrievals Figure 2 shows another example related to a bank account, The balances of the two bank accounts, A=200 and B=200 initially

Figure 2. - Transaction V transfers a sum from account A to B and - Transaction W invokes the branch Total method to obtain the sum of the balances of all the accounts in the bank. The result of branchTotal includes the sum of A and B as $300, which is wrong. This is an illustration of the inconsistent retrievals problem. Ws retrievals are inconsistent because V has performed only the withdrawal part of a transfer at the time the sum is calculated. Serial equivalence If each of several transactions is known to have the correct effect when it is done on its own, then we can infer that if these transactions are done one at a time in some order the combined effect will also be correct. An interleaving of the operations of transactions in which the combined effect is the same as if the transactions had been

performed one at a time in some order is a serially equivalent interleaving. When we say that two different transactions have the same effect as one another, we mean that the read operations return the same values and that the instance variables of the objects have the same values at the end. The use of serial equivalence as a criterion for correct concurrent execution prevents the occurrence of lost updates and inconsistent retrievals. The lost update problem occurs when two transactions read the old value of a variable and then use it to calculate the new value. This cannot happen if one transaction is performed before the other, because the later transaction will read the value written by the earlier one. As a serially equivalent interleaving of two transactions produces the same effect as a serial one, we can solve the lost update problem by means of serial equivalence. Figure 3 shows one such interleaving in which the operations that affect the shared account, B, are actually serial, for transaction T does all its operations on B before transaction U does. Another interleaving of T and U that has this property is one in which transaction U completes its operations on account B before transaction T starts. We now consider the effect of serial equivalence in relation to the

Figure 3. inconsistent retrievals problem, in which transaction V is transferring a sum from account A to B and transaction W is obtaining the sum of all the balances see figure 2. The inconsistent retrievals problem can occur when a retrieval transaction runs concurrently with an update transaction. It cannot occur if the retrieval transaction is performed before or after the update transaction. A serially equivalent interleaving of a retrieval transaction and an update transaction, for example as in figure 4. will prevent inconsistent retrievals occurring.

Figure 4.

Conflicting operations - When we say that a pair of operations conflicts we mean that their combined effect depends on the order in which they are executed. - To simplify matters we consider a pair of operations, read and write. read accesses the value of an object and write changes its value. - The effect of an operation refers to the value of an object set by a write operation and the result returned by a read operation. - The conflict rules for read and write operations are given in figure 5.

Figure 5 For any pair of transactions, it is possible to determine the order of pairs of conflicting operations on objects accessed by both of them. Serial equivalence can be defined in terms of operation conflicts as follows: For two transactions to be serially equivalent, it is necessary and sufficient that all pairs of conflicting operations of the two transactions be executed in the same order at all of the objects they both access. Consider as an example the transactions T and U, defined as follows: T: x = read(i); write(i, 10); write(j, 20); U: y = read(j); write(j, 30); z = read (i); Then consider the interleaving of their executions, shown in figure 6.

Figure 6 Note that each transactions access to objects i and j is serialized with respect to one another, - because T makes all of its accesses to i before U does and U makes all of its accesses to j before T does. - But the ordering is not serially equivalent, because the pairs of conflicting operations are not done in the same order at both objects. - Serially equivalent orderings require one of the following two conditions: 1. T accesses i before U and T accesses j before U. 2. U accesses i before T and U accesses j before T. approaches to concurrency control Three alternative approaches to concurrency control are commonly used: 1. locking, 2. optimistic concurrency control and

3. timestamp ordering. However, most practical systems use locking, When locking is used, the server sets a lock, labelled with the transaction identifier, on each object just before it is accessed and removes these locks when the transaction has completed. While an object is locked, only the transaction that it is locked for can access that object; other transactions must either wait until the object is unlocked or, in some cases, share the lock. The use of locks can lead to deadlocks, with transactions waiting for each other to release locks for example, when a pair of transactions each has an object locked that 4the other needs to access.