Chapter 20

Chapter 20 Concurrency Control

Objectives

To study how the (C and I) properties of transactions may be ensured under concurrent execution.

Points to emphasise

The concepts established in Ch 18 are not just applicable to TP systems.

Concurrent execution of composite operations can take place in concurrent programs in main memory in centralised and distributed systems. The C and I properties must be ensured by some means.

2PL is a pessimistic method. It achieves Consistency through guaranteeing a serialisable schedule of the operations of concurrent transactions. It has the overhead of deadlock management. Objects are locked for longer than is necessary for their invocation. We can enforce Isolation in the implementation through strict 2PL.
TSO is a pessimistic method. It achieves Consistency by enforcing one specific serial order on the transactions. It is deadlock free but correct transactions can be rejected. Isolation can be enforced by extending to strict TSO. Decisions are taken at each object rather than centrally.
In OCC we assume that contention is unlikely. We could only achieve a guaranteed consistent set of shadows in OCC by a pessimistic approach. We therefore optimistically choose to invoke operations on shadow objects which may turn out to be inconsistent.
When a transaction requests commit in OCC a validation phase ensures that the shadows used by the transaction were consistent and that no conflicting updates have been made to the persistent object states since the shadows were taken. The updates are then guaranteed to be made at each persistent object in the order in which the transactions committed.
OCC achieves high object availability by relaxing the guarantee of consistency.

Possible difficulties

2PL and TSO with strict execution are straightforward. Without strictness, cascading aborts may result and state recovery procedures may be needed (see Chapter 18). OCC is more difficult to understand because it restricts concurrency as little as possible. It is implicitly non-strict because the set of shadows are not guaranteed to represent a consistent state. Invocations take place in isolation once the shadows are taken and when commit is requested all are considered together. Serialisability is achieved when the updates are applied.

Teaching hints

The examples given in the chapter are simple and intended to reinforce the concepts.
Discuss different types of system and their requirements. When must we have high object availability so that timing constraints can be met? When is contention unlikely? What are "hot spots"?
Figure 21.4 shows validation and update for OCC in a distributed system.
The solutions in edition 1 to the additional exercises for Chapter 18 contained some figures which are included for extra explanation in Chapter 19 of edition 2, Figures 19.8 - 19.11.
The OCC example in Section 19.6 (Figure 19.13) shows that our definition of conflict, based on serialisability, may be over-restrictive for this method. Although these issues are interesting they are taking us to current research.