17-1 What problems might occur if the sub-operations of a single high level operation are started off in parallel (for example, for running on a shared memory multiprocessor)? Give examples. Why is it difficult to automate this approach?

The semantics of the high level composite operation may be such that an ordering is required on the sub-operations. It is difficult to automate this approach to achieving concurrency because the orderings depend on the application. For example, it may be necessary to read several values, perform a computation and write a value which is subsequently used by other sub-operations. A simple example is transfer requiring check-balance and debit to be done before credit.

17-2 Find out about the consistency checks your local operating system runs on its filing system on restarting after a crash or shutdown (an example is UNIX’s fsck maintenance tool). Is it possible for users to lose data? If so, how are they informed of this possibility? Why is this approach not possible in a transaction processing system?

This is system dependent. It is common for filing systems to scavenge and tell you when they have had to make an attempt to recover a consistent version of a file which may not reflect all of the work done when the crash occurred. You may have had successful returns from system calls which write to a file but still lose this data on a crash.

Transaction systems must guarantee that when the client is told that a transaction is done (committed) the result will persist in spite of any subsequent crashes or media failures. The system updates the persistent store then acknowledges commit to the client. A crash during a transaction will automatically imply abort. Because each operation is atomic, values can be restored to the state prior to the transaction whatever had happened when the crash occurred.

The requirements of transaction systems make file-system-style consistency checks inappropriate and the implementation of transaction systems makes them unnecessary.

17-3 To what extent is it desirable to run the sub-operations of different high level operations in parallel? What are the possible problems arising from uncontrolled concurrency? (Give examples of incorrect output and incorrect system state). What are the possible consequences of attempting to solve these problems?

This question reinforces Section 17.5 where examples are given. Uncontrolled concurrency can lead to incorrect output, for example, inconsistent, (uncommitted) system state may be seen, and incorrect state, for example because of lost updates.

If we allow interleaving in general but attempt to solve the problems by allowing objects to be locked by transactions, deadlock might arise. Other approaches to solving the problems might lead to many aborted transactions and complex, inefficient, procedures for recovering system state in order to effect these aborts.

17-4 What are the possible effects of a crash part-way through a single composite operation? What mechanisms must be in place to allow for the possibility of a crash at any time in a transaction processing (TP) system? Are these mechanisms suitable for handling concurrent execution of composite operations as well?

The point to emphasise here is that each component operation is implemented atomically and some may have completed when the crash occurs (in contrast with the single atomic operation of Chapter 13). If the partially complete high level operation is to be undone then all its component operations must be undone, even those that have finished.

If we have to be in a position to undo any operation in order to recover from a crash (either by restoring prior state or by applying an inverse operation) we can perhaps use the same mechanism to undo operations when concurrent execution has caused incorrect values to be recorded or used. This will have to be detected.

17-5 Why is it important, when designing a TP system, to have estimates of:

In some applications the data will have hot spots which are accessed frequently, even though conflict over most of the data may be unlikely.

17-6 Consider how you would set up an object model for a TP system. What are possible disadvantages of treating read and write as operations on data objects?

This is arguing for an O-O approach to database design. The approach works well through Part III for reasoning about the behaviour of systems. The definition of conflicting operations is more meaningful in terms of the operations on the object rather than just reading and writing its value. It is useful to refer back to the atomic operations in main memory discussed in Part II. Reading and writing locations in main memory are the components of a higher level operation such as "add record to linked list".

When we come to recovery in Chapter 20 we require operations to be undo-able and redo-able and that undo and redo are idempotent in case of a crash during recovery. In that chapter we move to an implementation of recovery based on recording object state.