30-1 What problems arise in a TP monitor from using one operating system process per user terminal?

This approach is common in general purpose OS. It may be suitable for small TP systems but does not scale well to systems where there is a large number of terminals. It might be required to extend to a process per terminal per component of a distributed system.

A large number of OS processes means too much space for per-process data structures and too much time in processing them. It is also difficult to give certain application functions low priority at times of heavy load. Priority tends to be associated with processes, not what they are doing.

30-2 How do the problems which arise when single threaded processes are used for building multi-threaded servers apply to TP system implementations? How have these problems been addressed in practice?

Suppose we have threads at language level only. Suppose each thread is associated with a terminal. If a thread makes a synchronous, blocking system call the whole process is blocked. Also, threads share an address space and there is no inter-thread protection. The problems have been addressed by implementing asynchronous I/O interfaces and by standard techniques for achieving protection by software, such as by using a strongly typed programming language.

30-3 Why is connection oriented communication between the components of a TP system less elegant than an RPC system? Why might it be more efficient?

The processes which comprise the distributed components of the TP system set up appropriate long term connections. These are used for the communications of many transactions. The programmer must manage this shared use of the communication channel.

The configuration of a TP system may vary. The programmer must be aware when to use same machine procedure call and cross machine message passing via a connection.

RPC supports a separate communication per transaction and might be implemented transparently to the programmer. RPC could be less efficient than a permanent connection but the RPC system could cache the destination addresses of frequently used remote procedure names.

30-4 Why is the use of a separate process for each component of a TP system more flexible than a shared address space solution?

So that a system may be configured and reconfigured without changing the component programs.

30-5 Indicate where buffered transaction processing is used when goods are paid for by cheque, credit card and debit card. How could online TP be brought into point of sale applications?

The approach is to batch transactions throughout. At present, debit cards function in the same way as cheques and credit cards. Batches are assembled at each vendor and at the vendors’ banks. The central clearing bank creates a batch of transactions for each member bank.

Online TP could be brought into point of sale in theory. The bank account of the purchaser could be interrogated on-line and the debit made. The system would have to be made failure tolerant.

30-6 What are the factors affecting the design of PIN-based authentication?

The PIN must never be transmitted or stored in clear. It must never be printed so that an employee can see it and associate it with an individual.

What would be the problems arising from a 12 digit PIN?

We would forget it or we would write it down.

Why shouldn’t I choose a PIN and tell my card issuer by writing it on a form?

This could be done if a special form with no personal information and with an encrypted account number was used. There could be a risk that those dispatching the form might be see the encrypted account number and the name and address to which it was sent and this process would have to be automated.

30-7 What would be involved in keeping the bank accounts in the bank account database computers and the ATM controllers completely up-to-date?

How to handle replicas is a general question encountered in large-scale distributed system design. A short discussion is given in Section 20.2. The choice is between consistency and availability. We can use a protocol such as 2PC to lock all replicas and propagate and update, or, less stringently, quorum assemble. Or we can live with a degree of inconsistency. In this application it might be that the model of a primary copy with replicas for efficient access is appropriate.

30-8 Why are TP benchmarks needed?

So that TP systems can be compared by purchasers and so that conflicts between purchaser and provider can be resolved. That is, the provider of a system may define its performance in terms of accepted benchmarks. A purchaser in dispute with the provider may be able to demonstrate that the performance is inadequate with respect to the benchmark.