7. Chapter 7: Transaction and Concurrency Control

7.1. Introduction

Simple synchronization (without transactions)

  1. Server is performed on behalf of different clients and may sometimes interfere with one another. 
  2. The use of threads allows operations from multiple clients to run concurrently and possibly access the same objects. 
  3. The use of synchronized keyword from Java ensure that only one thread at a time can access an object. 
  4. If one thread invokes a synchronized method on an object, then that object is effectively locked, and another thread that invokes one of its synchronized methods will be blocked until the lock is released. 
  5. It forces the execution of threads to be separated in time.

Enhancing client operation by synchronization of server operations

  • This scheme prevent threads from interfering with one another. 
  • But, some applications require a way for threads to communicate with each other.
  • Java wait and notify allow threads to communicate with one another. 
    • wait – the thread call wait on an object suspend itself and to allow another thread to executed a method of that object.
    • notify – to inform any thread waiting on that object that it has changed some of its data
  • Without the ability of synchronize, client might need to told to try again later and this will involve in polling the server and the server carrying out extra requests. 
  • It is also potentially unfair as other clients may make their requests before the waiting client tries again. 

1. Failure model for transactions

  • Failures of disks, servers and communication
  • Claim that the algorithms work correctly in the presence of predictable faults, but no claims are made about their behaviour when a disaster occurs. 
  • The model states:
    • Failures of disks
      • Writes to permanent storage may fail, either by writing nothing or by writing a wrong value. 
      • File storage may decay. 
      • Reads from permanent storage can be detected (by a checksum) when a block of data is bad. 

2. Failures of servers

  • Servers may crash occasionally.
  • When a crashed server is replaced by a new process, its volatile memory is first set to state in which it knows none of the values from before the crash. 
  • After that it carries out a recovery procedure using information in permanent storage and obtained from other processes to set the values of objects.
  • When a processor is faulty, it is made to crash so that it is prevented from sending erroneous messages and from writing wrong values to permanent storage – can’t produce arbitrary failures.
  • Crashes can occur at any time; may occur during recovery.

3. Failures of communication

  • There may be arbitrary delay before a message arrives. 
  • A message may be lost, duplicated or corrupted. 
  • The recipient can detect corrupted messages using a checksum.
  • Both forged messages and undetected corrupt messages are regarded as disasters.