La révolution transactionnelle n'a comme équivalent en informatique que la naissance de la mécanographie au moment où Hermann Hollerith a mécanisé le recensement américain de 1890.

Le traitement mécanographique des informations s'est fait par lots depuis cette date. Il faut noter que cette méthode d'opération correspondait à presque toutes les opérations manuelles de traitement d'information telles que les statistiques dont le recensement, la comptabilité, les bilans des entreprises, la paye des employés, les taxes qui sont par nature ou par habitude des opérations "batch" et qui le restent encore aujourd'hui. La réalité est échantillonnée sur une base annuelle, trimestrielle, mensuelle ou quotidienne. On ne sait pas encore bien à l'heure actuelle l' influence de la fréquence d'échantillonnage sur le système économique, mais il est probable qu'une partie du bruit remarqué dans le système boursier a quelque chose à voir avec la fréquence des indicateurs. Cependant, comme il y a des bénéficiaires institutionnels de ce bruit, comme il y a toujours des réticences aux changements, nombre de processus desservis maintenant par les ordinateurs restent soumis aux règles de batch processing. Cela durera aussi longtemps qu'on n'aura pas su repenser les systèmes de régulation micro-économiques.

Par contre, certains problèmes de traitement d'informations de gestion sont par nature peu conformes au traitement par lots. Certes, on  a pensé dans les années 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 durée de  l'interaction avec un client.

C'est ainsi qu'est née à la fin des années 1950 des réflexions à la fois dans les entreprises et chez les constructeurs sur un usage différent de l'informatique naissante. La gestion en temps réel des stocks ne pouvait que rarement se satisfaire d'informations sur un support d'accès séquentiel (cartes perforées ou bandes magnétiques) ayant un temps d'accès dépassant 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 réflexion menée en ce sens au laboratoire IBM de San José conduisit au développement du disque magnétique RAMAC puis de différents essais de supports qui ne parvinrent pas d'ailleurs à supplanter les disques. 

Un ordinateur de recherche dans un dispositif de stockage "à accès aléatoire" ne représentait pas toutefois qu'un aspect de la solution du problème. Le temps d'accès pour inférieur qu'il soit devant les solutions "humaines" était non négligeable et les performances d'un système tel que le RAMAC 305 ne suffisaient pas aux besoins des entreprises devant mobiliser plusieurs employés à la gestion d'une catégorie de stocks. Il est inutile de préciser que le prix d'un RAMAC pour inférieur qu'il fut à un IBM 705 ou un Gamma 60 de l'époque était bien supérieur à celui d'un PC et au salaire mensuel de l'employé qui le servait.

Pour pouvoir gérer en temps réel les stocks par plusieurs employés simultanément, soit pour des raisons d'emplacements de postes de travail, soit parce que l'opération de mise à jour s'accompagnait d'un dialogue avec le client, il était nécessaire de supporter plusieurs terminaux connectés à ordinateur gérant le stock. Deux solutions divisèrent la communauté informatique des années 1960, la première comportait un ordinateur frontal regroupant les messages et préparant le traitement dans un ordinateur de gestion de la base d e données, l'autre donnait à un seul ordinateur la gestion de toute la transaction. En pratique, la première solution fut aussi utilisée sous couvert d'un ordinateur unique (dans IMS de IBM par exemple), le mise en queue des messages étant faite par un processus spécialisé.
La seconde solution fut employée à l'origine dans des systèmes spéciaux où une amélioration de la productivité des opérateurs devait être obtenue par une gestion de terminaux étroitement liée à l'application. C'est dans ce dernier contexte que se développa le système SABRE de réservation de places, qui fut et qui, reste encore l'archétype des systèmes transactionnels.

En fait, la mise en place dans les entreprises d'un système transactionnel s'effectua en plusieurs phases. La première étant souvent l'utilisation de terminaux pour la saisie interactive d'informations traitées en batch la nuit. Cette saisie permettait de faire l'économie de la phase vérification d'un traitement mécanographique traditionnel. Dans d'autres cas, la priorité était donnée à l'instauration d'un système de consultation (sans mise à jour) d'informations permettant l'accès à certaines bases de données 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 systèmes survivront encore longtemps, le besoin de lire étant supérieur à celui de créer. 
Les différences de besoins en terme de droit d'accès, de fréquence de consultation ainsi que les réorganisations dans les entreprises ne permirent pas la réalisation des rêves de certains concepteurs, comme Charlie Bachmann, de voir triompher un modèle de système intégré où toutes les données du système d'informations serait regroupé dans une unique base de données, image virtuelle de l'entreprise. Le système dût être découpé en sous-systèmes relativement indépendants et interconnectés le plus souvent par des opérations séquentielles de traitement par lots. Ce découpage était souvent motivé par les besoins exprimés par les différentes 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 réalité de l'analyse des problèmes et de permettre leur évolution. Il est à noter que la maturité du système d'informatique de gestion a souvent coïncidé avec l'externalisation de l'informatique, externalisation désirée ou crainte des fournisseurs et des informaticiens. C'est ainsi que American Airlines, le pionnier de SABRE, a finalement confié son système à une compagnie indépendante, finalement achetée par EDS.

Caractéristiques des transactions

Atomicité

Consistance

Isolation

Durabilité

Conséquences sur les systèmes d'exploitation des ordinateurs.

Protection
Une des caractéristique des systèmes transactionnels est que le déploiement des applications est un évènement aussi notable que la mise en service d'une nouvelle usine ou d'une ligne de communication. Le développement et les tests de l'application sont des phases séparées et la maintenance ne peut se faire par des essais de fonctionnement sur le système en service. Il y a donc une différence assez grande entre systèmes transactionnels et systèmes de développements en time-sharing, même si les matériels sont similaires. Il n'est pas question de donner un accès Internet Telnet à un système bancaire, ce qui a comme conséquence d'isoler le réseau applicatif de la plupart des pénétrations externes. Je me souviens d'avoir fait avouer à des hackers du SRI (mandatés par la NSA) leur impuissance à pénétrer le système SABRE à un moment où non seulement GCOS et l'OS/MVT mais Multics et TSS avaient succombé à leurs attaques.
Cependant, il faut qu'un système transactionnel ne s'effondre pas s'il est sollicité par un message saugrenu, erroné volontairement ou non. Il faut donc que l'exécution d'une transaction ne puisse monopoliser des ressources critiques soit directement, soit indirectement par un usage abusif de ressources système partagées. 

Intégrité
Un système transactionnel doit garantir que les effets extérieurs des transactions terminées aient leur intégrité garantie. Le client est en droit de revendiquer que ce qui lui  a été vendu soit sa propriété. Ceci implique que les divers aléas informatiques n'aient pas d'autre impact que la détérioration du temps de service. Ces aléas avaient souvent  jadis des causes matérielles (pannes du processeur ou de support des bases de données. Ils sont aujourd'hui des défauts d'intégrité soit du logiciel, ou des impasses de conception du logiciel d'application. Ils étaient et restent encore inhérents à la logique du système transactionnel où plusieurs clients peuvent être en train simultanément de rechercher le fond du stock de produits et le moins rapide à se décider peut avoir de mauvaises surprises. Il n'est d'ailleurs pas possible d'assurer la permanence du service lorsque la base données doit être dynamiquement mise à jour par un programme batch de renouvellement de stock ou d'extraction de stocks périssables. Il est nécessaire dans ce cas que le système transactionnel mime au mieux le comportement normal d'un processus humain.

Pour cela un mécanisme de contrôle de la concurrence entre threads doit être créé et il doit couvrir tous les accès aux bases de données y compris ceux du batch processing. En cas d'étreinte fatale, le mécanisme doit tuer la thread la moins coûteuse à recommencer. Bien entendu, il est nécessaire d'annuler toutes les modifications faites sur les bases de données avec un journal des modifications.

Commitment
la primitive la plus innovante d'un système transactionnel s'appelle la prise de commitment: "j'ai fini mon travail, vous pouvez relâcher 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 système distribués -et il n'est pas infréquent que l'ordinateur terminal en est un- le commitment doit se prendre en deux phases, l'une de préparation, l'autre de commitment effectif.

Évolution des systèmes transactionnels.

Entre 1980 et 1985, alors qu'on pouvait penser que les systèmes transactionnels avaient atteint leur maturité avec CICS/VS et TDS, la généralisation 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 capacités de traitement des PC pour décharger 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 mémoire du ordinateur par l'application. Le retard à la disponibilité d'outils de création d'applications distribuées provoqua la vogue d'une remise en question du modèle transactionnel. Les applications de l'avenir  seraient client-serveur et les mainframes seraient remplacés par de simples serveurs de bases de données à qui les ordinateurs individuels transmettraient des requêtes SQL. La mémoire de la transaction encours serait conservée dans le PC et pourrait, si besoin était, être accédée par le central. L'avantage de ce modèle était essentiellement l'abaissement du coût du matériel nécessaire et l'utilisation de logiciel standard, même de logiciel libre. 
En fait, les premiers utilisateurs s'étant embarqué dans ce paradigme client/serveur durent constater que la réalité des problèmes posés par leur application entraînait une complexité aggravée par la nécessaire centralisation de serveurs de sécurité, de distribution de programmes, d'administration de réseau et des problèmes de synchronisation de bases de données distribuées. Certains durent faire en hâte marche arrière à l'occasion de la remise à jour des problèmes liés à l'an 2000 -masquant leur retard à la mise au point des systèmes distribués.

Il est certain que beaucoup de problèmes transactionnels sont plus économiquement gérés par des systèmes distribués à base de PC, à condition que leur système d'exploitation soit doté de fonctions mises au point pour les mainframes, ce qui ne s'est répandu qu'à la fin du XXe siècle et que le traitement de la transaction n'implique pas d'autres ordinateurs autres que le seul client et leurs serveurs.