La rvolution transactionnelle n'a comme quivalent en informatique que la naissance de la mcanographie au moment o Hermann Hollerith a mcanis le recensement amricain de 1890.

Le traitement mcanographique des informations s'est fait par lots depuis cette date. Il faut noter que cette mthode d'opration correspondait presque toutes les oprations manuelles de traitement d'information telles que les statistiques dont le recensement, la comptabilit, les bilans des entreprises, la paye des employs, les taxes qui sont par nature ou par habitude des oprations "batch" et qui le restent encore aujourd'hui. La ralit est chantillonne sur une base annuelle, trimestrielle, mensuelle ou quotidienne. On ne sait pas encore bien l'heure actuelle l' influence de la frquence d'chantillonnage sur le systme conomique, mais il est probable qu'une partie du bruit remarqu dans le systme boursier a quelque chose voir avec la frquence des indicateurs. Cependant, comme il y a des bnficiaires institutionnels de ce bruit, comme il y a toujours des rticences aux changements, nombre de processus desservis maintenant par les ordinateurs restent soumis aux rgles de batch processing. Cela durera aussi longtemps qu'on n'aura pas su repenser les systmes de rgulation micro-conomiques.

Par contre, certains problmes de traitement d'informations de gestion sont par nature peu conformes au traitement par lots. Certes, on  a pens dans les annes 1950 repenser l'entreprise autour de l'ordinateur, mais cette approche s'est heurt la reconnaissance de l'importance conomique de facteurs comme le volume des stocks ou bien la dure de  l'interaction avec un client.

C'est ainsi qu'est ne la fin des annes 1950 des rflexions la fois dans les entreprises et chez les constructeurs sur un usage diffrent de l'informatique naissante. La gestion en temps rel des stocks ne pouvait que rarement se satisfaire d'informations sur un support d'accs squentiel (cartes perfores ou bandes magntiques) ayant un temps d'accs dpassant la minute et donc peu susceptible de remplacer la recherche par un humain dans un support papier  aid ou non d'outils comme les fiches Rolodex ou de ses concurrents. La rflexion mene en ce sens au laboratoire IBM de San Jos conduisit au dveloppement du disque magntique RAMAC puis de diffrents essais de supports qui ne parvinrent pas d'ailleurs supplanter les disques. 

Un ordinateur de recherche dans un dispositif de stockage " accs alatoire" ne reprsentait pas toutefois qu'un aspect de la solution du problme. Le temps d'accs pour infrieur qu'il soit devant les solutions "humaines" tait non ngligeable et les performances d'un systme tel que le RAMAC 305 ne suffisaient pas aux besoins des entreprises devant mobiliser plusieurs employs la gestion d'une catgorie de stocks. Il est inutile de prciser que le prix d'un RAMAC pour infrieur qu'il fut un IBM 705 ou un Gamma 60 de l'poque tait bien suprieur celui d'un PC et au salaire mensuel de l'employ qui le servait.

Pour pouvoir grer en temps rel les stocks par plusieurs employs simultanment, soit pour des raisons d'emplacements de postes de travail, soit parce que l'opration de mise jour s'accompagnait d'un dialogue avec le client, il tait ncessaire de supporter plusieurs terminaux connects ordinateur grant le stock. Deux solutions divisrent la communaut informatique des annes 1960, la premire comportait un ordinateur frontal regroupant les messages et prparant le traitement dans un ordinateur de gestion de la base d e donnes, l'autre donnait un seul ordinateur la gestion de toute la transaction. En pratique, la premire solution fut aussi utilise sous couvert d'un ordinateur unique (dans IMS de IBM par exemple), le mise en queue des messages tant faite par un processus spcialis.
La seconde solution fut employe l'origine dans des systmes spciaux o une amlioration de la productivit des oprateurs devait tre obtenue par une gestion de terminaux troitement lie l'application. C'est dans ce dernier contexte que se dveloppa le systme SABRE de rservation de places, qui fut et qui, reste encore l'archtype des systmes transactionnels.

En fait, la mise en place dans les entreprises d'un systme transactionnel s'effectua en plusieurs phases. La premire tant souvent l'utilisation de terminaux pour la saisie interactive d'informations traites en batch la nuit. Cette saisie permettait de faire l'conomie de la phase vrification d'un traitement mcanographique traditionnel. Dans d'autres cas, la priorit tait donne l'instauration d'un systme de consultation (sans mise jour) d'informations permettant l'accs certaines bases de donnes de l'entreprise mises jour sur une base quotidienne, conomisant ainsi l'impression et la diffusion de gros volumes de papier de valeur fugitive. De tels systmes survivront encore longtemps, le besoin de lire tant suprieur celui de crer. 
Les diffrences de besoins en terme de droit d'accs, de frquence de consultation ainsi que les rorganisations dans les entreprises ne permirent pas la ralisation des rves de certains concepteurs, comme Charlie Bachmann, de voir triompher un modle de systme intgr o toutes les donnes du systme d'informations serait regroup dans une unique base de donnes, image virtuelle de l'entreprise. Le systme dt tre dcoup en sous-systmes relativement indpendants et interconnects le plus souvent par des oprations squentielles de traitement par lots. Ce dcoupage tait souvent motiv par les besoins exprims par les diffrentes baronnies qui n'avaient pas toujours pour objectif l'optimisation de l'entreprise dans son ensemble, mais il avait pour avantage d'tre adapt la ralit de l'analyse des problmes et de permettre leur volution. Il est noter que la maturit du systme d'informatique de gestion a souvent concid avec l'externalisation de l'informatique, externalisation dsire ou crainte des fournisseurs et des informaticiens. C'est ainsi que American Airlines, le pionnier de SABRE, a finalement confi son systme une compagnie indpendante, finalement achete par EDS.

Caractristiques des transactions

Atomicit

Consistance

Isolation

Durabilit

Consquences sur les systmes d'exploitation des ordinateurs.

Protection
Une des caractristique des systmes transactionnels est que le dploiement des applications est un vnement aussi notable que la mise en service d'une nouvelle usine ou d'une ligne de communication. Le dveloppement et les tests de l'application sont des phases spares et la maintenance ne peut se faire par des essais de fonctionnement sur le systme en service. Il y a donc une diffrence assez grande entre systmes transactionnels et systmes de dveloppements en time-sharing, mme si les matriels sont similaires. Il n'est pas question de donner un accs Internet Telnet un systme bancaire, ce qui a comme consquence d'isoler le rseau applicatif de la plupart des pntrations externes. Je me souviens d'avoir fait avouer des hackers du SRI (mandats par la NSA) leur impuissance pntrer le systme SABRE un moment o non seulement GCOS et l'OS/MVT mais Multics et TSS avaient succomb leurs attaques.
Cependant, il faut qu'un systme transactionnel ne s'effondre pas s'il est sollicit par un message saugrenu, erron volontairement ou non. Il faut donc que l'excution d'une transaction ne puisse monopoliser des ressources critiques soit directement, soit indirectement par un usage abusif de ressources systme partages. 

Intgrit
Un systme transactionnel doit garantir que les effets extrieurs des transactions termines aient leur intgrit garantie. Le client est en droit de revendiquer que ce qui lui  a t vendu soit sa proprit. Ceci implique que les divers alas informatiques n'aient pas d'autre impact que la dtrioration du temps de service. Ces alas avaient souvent  jadis des causes matrielles (pannes du processeur ou de support des bases de donnes. Ils sont aujourd'hui des dfauts d'intgrit soit du logiciel, ou des impasses de conception du logiciel d'application. Ils taient et restent encore inhrents la logique du systme transactionnel o plusieurs clients peuvent tre en train simultanment de rechercher le fond du stock de produits et le moins rapide se dcider peut avoir de mauvaises surprises. Il n'est d'ailleurs pas possible d'assurer la permanence du service lorsque la base donnes doit tre dynamiquement mise jour par un programme batch de renouvellement de stock ou d'extraction de stocks prissables. Il est ncessaire dans ce cas que le systme transactionnel mime au mieux le comportement normal d'un processus humain.

Pour cela un mcanisme de contrle de la concurrence entre threads doit tre cr et il doit couvrir tous les accs aux bases de donnes y compris ceux du batch processing. En cas d'treinte fatale, le mcanisme doit tuer la thread la moins coteuse recommencer. Bien entendu, il est ncessaire d'annuler toutes les modifications faites sur les bases de donnes avec un journal des modifications.

Commitment
la primitive la plus innovante d'un systme transactionnel s'appelle la prise de commitment: "j'ai fini mon travail, vous pouvez relcher tous les verrous qu j'avais ferm". Cette primitive est implicite la fin de la transaction, mais peut aussi se prendre en cours. Lorsqu'elle concerne des systme distribus -et il n'est pas infrquent que l'ordinateur terminal en est un- le commitment doit se prendre en deux phases, l'une de prparation, l'autre de commitment effectif.

volution des systmes transactionnels.

Entre 1980 et 1985, alors qu'on pouvait penser que les systmes transactionnels avaient atteint leur maturit avec CICS/VS et TDS, la gnralisation du remplacement de terminaux traditionnels (3270 et VIP) par des micro-ordinateurs causa une certaine remise en cause des acquis. Les mainframers avaient d'abord pens utiliser les capacits de traitement des PC pour dcharger ordinateur central des fonctions de saisie et de mise en page de l'dition, voire de l'impression de documents et d'utiliser pour cela un mulateur de terminaux sans utiliser la mmoire du ordinateur par l'application. Le retard la disponibilit d'outils de cration d'applications distribues provoqua la vogue d'une remise en question du modle transactionnel. Les applications de l'avenir  seraient client-serveur et les mainframes seraient remplacs par de simples serveurs de bases de donnes qui les ordinateurs individuels transmettraient des requtes SQL. La mmoire de la transaction encours serait conserve dans le PC et pourrait, si besoin tait, tre accde par le central. L'avantage de ce modle tait essentiellement l'abaissement du cot du matriel ncessaire et l'utilisation de logiciel standard, mme de logiciel libre. 
En fait, les premiers utilisateurs s'tant embarqu dans ce paradigme client/serveur durent constater que la ralit des problmes poss par leur application entranait une complexit aggrave par la ncessaire centralisation de serveurs de scurit, de distribution de programmes, d'administration de rseau et des problmes de synchronisation de bases de donnes distribues. Certains durent faire en hte marche arrire l'occasion de la remise jour des problmes lis l'an 2000 -masquant leur retard la mise au point des systmes distribus.

Il est certain que beaucoup de problmes transactionnels sont plus conomiquement grs par des systmes distribus base de PC, condition que leur systme d'exploitation soit dot de fonctions mises au point pour les mainframes, ce qui ne s'est rpandu qu' la fin du XXe sicle et que le traitement de la transaction n'implique pas d'autres ordinateurs autres que le seul client et leurs serveurs.