Programming and transactional systems

The concept of transaction is part of the universal heritage of human societies, and is one of the regulating elements of the exchange function: the exchange of work for a wage, the exchange of one good or service for another, the association of two individuals and/or organizations with a view to a goal unattainable by each of the parties individually.

A transaction always involves three players:

• customers and suppliers are the actors in the exchange. They proceed according to an explicit protocol known to both parties; this protocol may vary according to the nature of the exchange. The "customer" requests a service or good, and the "supplier" offers the desired service or good;

• the "referee", or neutral observer, is the guarantor that the transaction has been carried out according to the rules. He or she countersigns the agreement of both parties, keeping an official record accessible to all.

It's hardly surprising, then, to find this concept at the heart of information systems, insofar as their ambition is to model the activity of individuals and/or organizations, with the aim of automating all or part of information management in line with corporate objectives.

Thus, in a banking transaction, such as a cash withdrawal, there must be "simultaneous" remittance of a certain sum of money to the customer, and debiting of the customer's account by the corresponding sum; the operation is carried out under the control of the — cashier, who may be an automatic ticket dispenser — who ensures the customer's solvency while guaranteeing that of the bank.

It is this indivisible block that forms the transaction. Either the rules that make up the transaction have been respected, and the transaction is declared valid, or they have not been respected, and the transaction is invalid, i.e. nothing has happened.

The notion of transaction is therefore closely associated with that of deontology and respect for rules of behavior. A transaction is a set of coherent actions that must have the same meaning for all players: it is therefore a fundamentally semantic notion.

The notion of transactional programming appeared explicitly in the late 60s and early 70s, with the first terminal networks and databases. We gradually moved from an exclusively batch world to that of interactive remote processing. In the process, a number of system problems hidden to programmers in batch mode became visible and inescapable for programmers of interactive applications.

In a batch...