7. Chapter 7: Transaction and Concurrency Control
7.1. Introduction
Simple synchronization (without transactions)
- Server is performed on behalf of different clients and may sometimes interfere with one another.
- The use of threads allows operations from multiple clients to run concurrently and possibly access the same objects.
- The use of synchronized keyword from Java ensure that only one thread at a time can access an object.
- 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.
- 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.