Transactionnel et

transactionnel réparti

Mars 2000 René J. Chevance

Contenu
! Introduction
! Concept de transaction - Propriétés ACID
! Caractéristiques du transactionnel
! Rôle d’un moniteur transactionnel
! Composantes d'un moniteur transactionnel
! Modèle de moniteur transactionnel
! Moniteur transactionnel
! Threads
! Modèle X/Open
! Transactionnel réparti - commitment à deux phases
! Exemple de moniteur transactionnel: Tuxedo
! Moniteurs transactionnels et SGBDs
Page 2

© RJ Chevance
 Introduction
! Le transactionnel est une dimension essentielle des systèmes
d'information des entreprises
! Un système transactionnel (OLTP On Line Transaction Processing)
fournit un cadre pour les applications critiques, il est fiable et à
haute performance
! Les besoins transactionnels ont conduit les constructeurs à
développer des systèmes ou des sous-systèmes spécifiques:
" Spécifique: TPF(IBM Mainframe) pour des systèmes très spécialisés
(e.g. système de réservation de la TWA)
" IBM: CICS sous-système transactionnel pour mainframe (environ
38000 installations) maintenant porté sur des systèmes UNIX (e.g.
CICS/6000). Produits compatibles sous UNIX tels qu'UNIKIX
(Integris/Bull)
! Bull: TDS sur Mainframe, DEC: ACMS,....
! Tandem: Pathway/Guardian pour ses systèmes à continuité de
service
! USL, Novell puis BEA : Tuxedo pour systèmes UNIX, NCR : Top End
pour UNIX
! Transarc: ENCINA pour UNIX
Page 3

© RJ Chevance

Concept de transaction - Propriétés ACID

! Rappel, on appelle transaction une séquence d'actions sur l'état
physique et logique d'une application qui respecte les propriétés
suivantes dites ACID (Atomicity, Consistency, Isolation,
Durability):

! Atomicité: Les changements opérés par une transaction sur l'état

sont atomiques: ils sont tous exécutés ou bien aucun ne l'est;
! Consistance: Une transaction est une transformation correcte de
l'état. L'ensemble des actions accomplies par la transaction ne
viole pas les contraintes associées avec l'état. Ceci implique que
la transaction soit un programme correct;
! Isolation: Bien que les transactions s'exécutent de façon
concurrentes, il apparaît, à chaque transaction que les autres
transactions, se sont exécutées soit avant soit après;
! Durabilité: Lorsqu'une transaction se termine avec succès
(commitement), le changement qu'elle a provoqué sur l'état doit
survivre aux défaillances.

Page 4

© RJ Chevance
 Caractéristiques du transactionnel
! Partage:
" en Lecture et Écriture
" par l’ensemble des utilisateurs
" Propriétés ACID
! Flux de requêtes irrégulier
! Travail répétitif
" Répertoire de fonctions pré-défini typiquement O(100) fonctions
! Fonctions simples
" Fonctions peu complexes (typiquement de 105 à 107 instructions et 10 E/S)
! Possibilité de traitement de type batch (avec respect des propriétés ACID)
! Grand nombre de terminaux (1000-10000)
! Clients intelligents (stations, PC, autres systèmes, terminaux)
! Haute disponibilité requise
" Recouvrement effectué par le système
" Fondé sur les propriétés ACID
! Taille des bases de données
" Proportionnelle à l'activité de la Société
! Peu de données "touchées" par une transaction
! Équilibrage de charge automatique
! Recherche de la performance au moyen du parallélisme inter-requête
! Performance : haut débit et temps de réponse garanti
Page 5 ! Scalabilité : exigence typique
© RJ Chevance

Rôle d ’un moniteur transactionnel

! Peu de systèmes d’exploitation ont été conçus
dans l’optique du transactionnel
! Le support d’un grand nombre d’utilisateurs et
d’un flux important de transactions (plusieurs
milliers par seconde) provoque un effondrement
des systèmes
! Le rôle d’un moniteur transactionnel est :
" Gestion des processus comprenant le lancement des
applications, le contrôle de leur déroulement et
l’équilibrage de charge (on peut parler de multiplexage
des requêtes sur les ressources du système)
" Gestion des transaction (respect des propriétés ACID)
dans un contexte, éventuellement distribué, mettant
en jeu plusieurs gestionnaires de données

Page 6

© RJ Chevance
 Modèle de moniteur transactionnel

Réseau Terminal

. Collecte les entrées des transactions

Message (gestion de formes)
Manager (MM) . Construit un format standard d'entrée
des requêtes
. Envoie les résultats (gestion de formes)

. Débute et termine les transactions

Request . Détermine le type des requêtes
Control (RC) . Dirige les requêtes vers les applications
appropriées

Application . Exécute les programmes d'application

Server (AS)

Database
System (DBMS) . Gère les données partagées

Page 7

© RJ Chevance

Composants d’un moniteur transactionnel

Presentation
Services

Service
Resource Call
Resource
Application Manager
Resource
Dispatch Application Manager
Resource
Program Service Call Manager
Application
Program Resource
Manager
TP Application
Program Manager
Monitor Finish Program
Join
Begin Work, Save Work, Transaction
Send/ Commit, Rollback Save Work
Receive Log records
Checkpoint
Register Incoming/ Prepare
Outgoing Transactions Commit
Communication Transaction Log
Manager Manager Manager
Savepoint UNDO/
Prepare REDO
Commit Log Records Savepoint
Preapred
Committed
Savepoint, Prepare, Commit Completed
Checkpoint

Page 8
Source [GRA93 ]
© RJ Chevance
 Concept de threads (processus légers)
! La gestion d'un grand nombre d'utilisateurs connectés et d'un grand
nombre de transactions actives dépasse, bien souvent, les capacités
de traitement des systèmes d'exploitation et du matériel les supportant
! Il convient d’alléger la gestion des contextes des utilisateurs, c’est-à-
dire ’éviter d'avoir un processus par utilisateur (trop de processus
conduit à un effondrement du système)
! Solution: les "threads", ou chemins d'exécution indépendants au sien
d'un même processus. Ceci correspond au multiplexage de processus
"légers" au sein d'un processus. Une commutation de thread au sein
d'un processus coûte environ 10 fois moins de temps qu'une
commutation de processus
! Le processus est l'unité d'allocation de ressources du point de vue du
système : protection, espace mémoire, fichiers, connections
réseau,.....Les threads partagent les ressources au sein du processus.
Bien évidemment, l'accès aux ressources partagées nécessite une
synchronisation
! Les threads sont supportés soit au niveau du système d'exploitation
(e.g. implémentation de la norme POSIX 1003.4a) soit au sein des
sous-systèmes eux-mêmes (e.g. moniteurs transactionnels, systèmes
Page 9 de gestion de bases de données,..)
© RJ Chevance

Notion de processus (Unix) et de thread

Exemple de structuration de 4GB

l'espace d'adressage virtuel
(Unix)
Code et
Système données
noyau

2GB

Process
2GB Librairies 2GB Utilisateur
Librairies Librairies 2GB
partagées partagées Multi-thread
partagées
Mémoire Mémoire
Mémoire
partagée partagée
partagée
Contexte Pro. Contexte Pro.
Contexte Pro. Contexte Pro.
Pile Pile
Pile Pile

Données Données
Données Thread 0 Thread n
Code (text) Code (text) 0
0 Code (text) 0
Utilisateur Utilisateur
Page 10 Mono-thread
Mono-thread
© RJ Chevance
 Notion de thread (Unix)
4GB
Code et
données
noyau
Partage des ressources "système » Système Ressources
entre les threads d'un processus Structure u associées au
processus

2GB

Process

Librairies 2GB
partagées
Mémoire
Utilisateur partagée
Multi-thread
Contexte Pro. Contexte Pro.
Notes:
- Deux threads "système" sont automatiquement Pile Pile
associés à un processus multi-thread pour la
gestion des threads "utilisateur »
(exemple scheduling, signaux,...) Données
- L'accès aux données communes au niveau Thread 0 Thread n
du processus nécessite une synchronisation Code (text) 0
entre les threads
Page 11

© RJ Chevance

Modèle X/Open

! Transactionnel centralisé

TM
Transaction Manager
Begin
Commit
Rollback Prepare, Commit, Rollback
(TX)
Application Join

Requests
RM
Resource Manager

Le modèle X/open suppose que les Resource Managers ont leurs propres services de log
et de verrouillage (lock) et que ces Resource Managers réalisent leurs propres reprises (rollback)
à la demande du Transaction Manager

Page 12

© RJ Chevance
 Modèle X/Open(2)
! Transactionnel distribué (DTP)
Site A Site B
Protocoles OSI/TP et CCR
prepare, commit, rollback
+ ack, - ack, restart
TM
TM Gestionnaire de transactions
Gestionnaire de transactions (OSI-TP+CCR)
Begin (XA+) (XA+)
Commit
Rollback Start
(TX) La transaction <transid> quitte ce nœud La transaction <transid> arrive sur ce nœud

Données de l’application CM CM Données de l’application

Application Application
Gestionnaire de Gestionnaire de « serveur »
communications communications
(C/S - Égal à égal) (C/S - Égal à égal)

Prepare, Commit, Rollback Prepare, Commit, Rollback Requêtes

(XA) (XA)
Requêtes

Requêtes distantes RM
RM ResourceRMManager
Gestionnaire de ressources Gestionnaire de ressources

Note: TM et CM peuvent être intégrés

Page 13

© RJ Chevance

Modèle X/Open(3)

! Standards
Eléments participant Protocole/API Organisme
Application:TM TX X/Open DTP
Application:RM spécifique du RM fournisseurs des RMs
Application:Serveur C/S ou Peer to Peer OSI + application
TM:RM XA X/Open DTP
TM:CM XA+ X/Open DTP
TM-TM OSI-TP + CCR OSI

- OSI définit des protocoles et des formats (FAP - Format And Protocols). Ceci est nécessaire
pour l'interopérabilité.

_ X/Open définit des interfaces de programmation API (Application Programming Interface).

Ceci est nécessaire pour la portabilité.

- C/S: Client/Seveur qui utilise souvent un RPC (Remote Procedure Call) spécifique

- Peer to Peer: dialogue d'égal à égal

- CR: Commit, Concurrency Control and Recovery

Note: OSI-TP est similaire à LU6.2 qui est un standard (FAP) de fait relatif aux interactions entre
clients et serveurs dans un environnement transactionnel.
Page 14

© RJ Chevance
 Validation à deux phases

! Cas centralisé [GRA93]

Coordinateur Participants
(Transaction Manager) (Resource Managers)

Prépare

Préparation locale
Préparation locale Ecriture (forcée) d'un enregistrement
"Prépare" dans le journal
OK

Ecriture (forcée) d'un enregistrement

"Commit" dans le journal
Commit

commitment local
Ecriture d'un enregistrement
"Complétion" dans le journal
Acquittement lorsque l'écriture
est durable
Ack
Ecriture d'un enregistrement
"Complétion" dans le journal

Page 15

© RJ Chevance

Validation à deux phases(2)

! Cas distribué [GRA93]

Etat courant

next tr_id Transaction Resource

Transactions actives
Manager Managers
tr_id Etat max. LSN {RM_ids} Sessions

Communication Log
Manager Manager

Sessions
Master Log

Autres Transaction
Managers

Page 16

© RJ Chevance
 Validation à deux phases(3)

! Cas distribué (suite)

Coordinateur Participants locaux Participants distribués
(Transaction Manager) (Resource Managers) (Transactions Managers)

Prépare
Préparation locale
Préparation locale
Prépare
.Préparation "distribuée" OK
Préparation locale
Préparation "distribuée"
Décision
"Prépare" -> Log
Acquitter
OK

Décision Commit
Ecriture (forcée) d'un
enregistrement Commit commitment local
"Commit" dans le journal

Ack commitment distribué

"Complete" "Complete"
Ecriture d'un enregistrement Acquitter
Page 17
"Complétion" dans le journal

© RJ Chevance

Validation à deux phases(4)

! Cas distribué (suite)

Transaction Manager "Coordinateur": Transaction Manager "Participant":

Commit Prépare()

. Préparation locale :"prépare" envoyé à chaque RM . Préparation locale :"prépare" envoyé à chaque RM local
local . Préparation "distribuée" : "prépare" envoyé à chacune
. Préparation "distribuée" : "prépare" envoyé O à chacune des sessions impliquées dans la transaction (en fait des TMs)
des sessions impliquées dans la transaction (en fait des •. Décision : Si tous les RM locaux et les sessions
TMs) impliquées répondent OK, le TM est quasi prêt
. Décision : Si tous les RM locaux et les sessions • Préparé : écriture d'un enregistrement "commit »
impliquées répondent OK, écriture d'un enregistrement avec les informations (RMs et TMs participants
"commit" avec toutes ces informations dans le journal) ainsi que le TM "parent" dans le journal)
. Commit : Envoi de l'ordre "commit" à tous les RM . Réponse : répondre positivement au demandeur
locaux et aux TM des sessions concernées . Attente : attente d'un ordre "commit" en provenance du
. "Complète" : Si tous les RM locaux et les toutes les coordinateur.
sessions impliquées (les TMs) répondent positivement
écriture (forcée) d'un enregistrement "complétion" dans Commit()
le journal. Après la fin d'écriture, mise à jour de l'état de
la transaction ("finie") . Commit : Envoi de l'ordre "commit" à tous les RM locaux
et aux TM des sessions concernées
Abort . "Complète" : Si tous les RM locaux et les toutes les
sessions impliquées (les TMs) répondent positivement
. "Broadcast Abort" : envoyer le message "abort" à écriture (forcée) d'un enregistrement "complétion" dans
toutes les sessions concernées le journal. Après la fin d'écriture, mise à jour de l'état de
. Défaire : défaire la transaction à l'aide des informations la transaction ("phase 2 terminée")
du journal . Acquittement : après l'écriture dans le journal, envoyer
. "Complète" : Ecriture d'un enregistrement dans le un acquittement du commit au coordinateur et mettre à
Page 18 journal et mise à jour de l'état de la transaction jour l'état (local) de la transaction

© RJ Chevance
 Exemple de moniteur transactionnel : Tuxedo
! Initialement développé par AT&T pour ses propres applications
transactionnelles sous Unix, repris ensuite par USL (Unix System
Laboratories), Novell et maintenant possession de BEA
! Début de commercialisation en 1989. Plusieurs milliers de
systèmes installés
! Disponible sur un grand nombre de systèmes
! Caractéristiques
" Conforme au modèle X/Open DTP (Distributed Transaction
Processing)
" Portabilité
" Support au niveau des langages de programmation (e.g. Visual
Basic, Cobol)
" Architecture Client/Serveur
" Management du système
" Multiplexage Clients - Serveurs
" Mécanisme de gestion de files d'attente de messages
" Transactions distribuées
" Sécurité
Page 19

© RJ Chevance

Tuxedo
! Architecture d'application
Applications
Tools, 4GL’s C, C++, COBOL

ATMI
TUXEDO
Distributed
System Client- Name Mngmnt Connectivity Transaction
Server Server & Admin Processing

System-Level Resource Manager(s)

(Hardware, Operating System,
Network)

ATMI : Application - Transaction Manager Interface

Page 20

© RJ Chevance
 Tuxedo(2)

! Architecture - Cas centralisé

Client Client
/T LIB /T LIB

Transaction et
Communication
Bulletin Board
SYSTEM /T Manager

/T LIB /T LIB /T LIB

Function 1 Function 1 Function n

<< >> >>
RM LIB RM LIB RM LIB

Resource Resource
Manager Manager

Page 21

© RJ Chevance

Tuxedo(3)

! Architecture - Cas distribué

WS Client WS Client

UNIX Server UNIX Server

WS Handler Unix Unix Unix

Client Client Client

DBBL

BBL Bulletin Board Bulletin Board BBL

TM
TM
Server Server /Host Server
Bridge Bridge

HOST

Page 22

© RJ Chevance
 Tuxedo(4)
! Composants
" Tuxedo System/T
# Composant principal de Tuxedo (fonctionne sous Unix)
# Serveur de Nom et Gestionnaire de Transactions (TM)
" Tuxedo System/WS
# Partie Client, fonctionne sous DOS/Windows, Unix et OS/2
" Tuxedo System/Host
# Permet à des services de Tuxedo de fonctionner sur des
systèmes propriétaires
" Tuxedo System/Q
# Mécanisme de mise en queue de messages respectant les
propriétés transactionnelles (soumission et achèvement
garantis)
# Gestionnaire de ressources (RM) conforme à XA
" Tuxedo System/TDomain
# Requêtes transactionnelles entre des domaines
d'administration séparés de Tuxedo
Page 23

© RJ Chevance

Moniteurs transactionnels et SGBD

! Il y a deux possibilités pour la programmation d'un système
transactionnel:
" Programmation Client/Serveur, sans moniteur
transactionnel, en relation avec les possibilités offertes par
les SGBDs. Ceci est appelé "TP Lite" ou transactionnel
léger
" Utilisation d'un moniteur transactionnel qui fournit le cadre
architectural des applications et utilisation des services
fournis par différents composants logiciels (e.g. SGBDs).
Ceci est appelé "TP Heavy" ou transactionnel lourd
! Pour le choix entre ces deux approches, différents éléments
rentrent en ligne de compte tels que:
" Transactionnel léger : dépendance vis à vis du fournisseur de
SGBD, limitations vis à vis de la programmation des transactions
(la validation est faite au niveau du SGBD), problèmes de
performance,...
" Pour TP Heavy: limitation potentielle dans les progiciels que l'on
peut intégrer, pérennité du moniteur, complexité de la
Page 24 programmation,....
© RJ Chevance
 Références

[BER97] Philip A. Bernstein, Eric Newcomer « Principles of Transaction

Processing »
Morgan Kaufmann, San Mateo, 1997
[BES97] Jérôme Besancenot, Michèle Cari, Jean Ferrié, Rachid Guerraoui,
Philippe Pucheral, Bruno Traverson, " Les systèmes transactionnels :
concepts, normes et produits "
Hermès Science, 1997
[GRA93] Jim Gray, Andreas Reuter « Transaction Processing: Concepts and,
Techniques »
Morgan Kaufmann, San Mateo, 1993

Page 25

© RJ Chevance