Transactionnel et transactionnel rØparti -...
-
Upload
truongduong -
Category
Documents
-
view
213 -
download
1
Transcript of Transactionnel et transactionnel rØparti -...
Transactionnel etTransactionnel etTransactionnel etTransactionnel ettransactionnel répartitransactionnel répartitransactionnel répartitransactionnel réparti
René J. ChevanceMars 2000
Page 2
© RJ 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 3
© 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 4
© RJ Chevance
Concept de transaction - Propriétés ACID
! Rappel, on appelle transaction une séquence d'actions sur l'étatphysique et logique d'une application qui respecte les propriétéssuivantes dites ACID (Atomicity, Consistency, Isolation,Durability):
! Atomicité: Les changements opérés par une transaction sur l'étatsont atomiques: ils sont tous exécutés ou bien aucun ne l'est;
! Consistance: Une transaction est une transformation correcte del'état. L'ensemble des actions accomplies par la transaction neviole pas les contraintes associées avec l'état. Ceci implique quela transaction soit un programme correct;
! Isolation: Bien que les transactions s'exécutent de façonconcurrentes, il apparaît, à chaque transaction que les autrestransactions, 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 doitsurvivre aux défaillances.
Page 5
© 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! Scalabilité : exigence typique
Page 6
© 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 (plusieursmilliers par seconde) provoque un effondrementdes 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 etl’équilibrage de charge (on peut parler de multiplexagedes requêtes sur les ressources du système)
" Gestion des transaction (respect des propriétés ACID)dans un contexte, éventuellement distribué, mettanten jeu plusieurs gestionnaires de données
Page 7
© RJ Chevance
Modèle de moniteur transactionnel
MessageManager (MM)
RequestControl (RC)
ApplicationServer (AS)
DatabaseSystem (DBMS)
Réseau Terminal
. Collecte les entrées des transactions (gestion de formes). Construit un format standard d'entrée des requêtes. Envoie les résultats (gestion de formes)
. Débute et termine les transactions
. Détermine le type des requêtes
. Dirige les requêtes vers les applications appropriées
. Exécute les programmes d'application
. Gère les données partagées
Page 8
© RJ Chevance
Composants d�un moniteur transactionnel
Presentation Services
TPMonitor
Application ProgramApplication
ProgramApplication ProgramApplication
Program
ResourceManagerResource
ManagerResourceManagerResource
ManagerResourceManager
Log records
Log Manager
Transaction Manager
Communication Manager
Send/Receive
Register Incoming/Outgoing Transactions
SavepointPrepareCommit
Savepoint, Prepare, Commit
UNDO/REDOLog Records Savepoint
PreapredCommittedCompletedCheckpoint
Save WorkCheckpointPrepareCommit
ServiceCall
Service CallDispatch
FinishJoinTransactionBegin Work, Save Work,
Commit, Rollback
Source [GRA93 ]
Page 9
© 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ésde 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 processusconduit à un effondrement du système)
! Solution: les "threads", ou chemins d'exécution indépendants au siend'un même processus. Ceci correspond au multiplexage de processus"légers" au sein d'un processus. Une commutation de thread au seind'un processus coûte environ 10 fois moins de temps qu'unecommutation de processus
! Le processus est l'unité d'allocation de ressources du point de vue dusystème : protection, espace mémoire, fichiers, connectionsréseau,.....Les threads partagent les ressources au sein du processus.Bien évidemment, l'accès aux ressources partagées nécessite unesynchronisation
! 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 dessous-systèmes eux-mêmes (e.g. moniteurs transactionnels, systèmesde gestion de bases de données,..)
Page 10
© RJ Chevance
Notion de processus (Unix) et de thread
Code etdonnéesnoyau
4GB
2GB
Système
Exemple de structuration del'espace d'adressage virtuel(Unix)
UtilisateurMono-thread
2GBLibrairiespartagéesMémoirepartagée
Pile
Données
Code (text) 0
Contexte Pro.
UtilisateurMono-thread
2GBLibrairiespartagéesMémoirepartagée
Pile
Données
Code (text) 0
Contexte Pro.
2GBLibrairiespartagéesMémoirepartagée
Données
Code (text) 0
Pile
Contexte Pro.
Pile
Contexte Pro.
Thread 0 Thread n
ProcessUtilisateurMulti-thread
Page 11
© RJ Chevance
Notion de thread (Unix)
Code etdonnéesnoyau
4GB
2GB
SystèmeStructure u
Ressourcesassociées auprocessus
UtilisateurMulti-thread
Partage des ressources "système » entre les threads d'un processus
Notes: - Deux threads "système" sont automatiquementassociés à un processus multi-thread pour la gestion des threads "utilisateur »(exemple scheduling, signaux,...)- L'accès aux données communes au niveau du processus nécessite une synchronisationentre les threads
2GBLibrairiespartagéesMémoirepartagée
Données
Code (text) 0
Pile
Contexte Pro.
Pile
Contexte Pro.
Thread 0 Thread n
Process
Page 12
© RJ Chevance
Modèle X/Open
! Transactionnel centralisé
Application
TMTransaction Manager
RMResource Manager
BeginCommitRollback (TX)
Requests
Join
Prepare, Commit, Rollback
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 13
© RJ Chevance
Modèle X/Open(2)! Transactionnel distribué (DTP)
Application
TMGestionnaire de transactions
RMGestionnaire de ressources
BeginCommitRollback (TX)
Requêtes
Prepare, Commit, Rollback (XA)
Application« serveur »
RMResource Manager
Prepare, Commit, Rollback (XA)
Données de l’application CMGestionnaire decommunications
La transaction <transid> quitte ce nœudStart
Requêtes
Requêtes distantes
Protocoles OSI/TP et CCR prepare, commit, rollback + ack, - ack, restart
(OSI-TP+CCR)
(C/S - Égal à égal) (C/S - Égal à égal)
(XA+) (XA+)
Note: TM et CM peuvent être intégrés
RMGestionnaire de ressources
Données de l’applicationCMGestionnaire decommunications
TMGestionnaire de transactions
Site A Site B
La transaction <transid> arrive sur ce nœud
Page 14
© RJ Chevance
Modèle X/Open(3)
! StandardsEléments partic ipant Protocole/API Organisme
Application:TM TX X/Open DTPApplication:RM spécifique du RM fournisseurs des RMs
Application:Serveur C/S ou Peer to Peer OSI + applicationTM:RM XA X/Open DTPTM:CM XA+ X/Open DTPTM-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 15
© RJ Chevance
Validation à deux phases
! Cas centralisé [GRA93]
Ecriture (forcée) d'un enregistrement"Commit" dans le journal
Coordinateur(Transaction Manager)
Participants(Resource Managers)
Prépare
Préparation localeEcriture (forcée) d'un enregistrement"Prépare" dans le journal
OK
Préparation locale
Commit
commitment localEcriture d'un enregistrement "Complétion" dans le journalAcquittement lorsque l'écriture est durableAck
Ecriture d'un enregistrement"Complétion" dans le journal
Page 16
© RJ Chevance
Validation à deux phases(2)
! Cas distribué [GRA93]
tr_id Etat max. LSN {RM_ids} Sessions
next tr_id
Etat courant
TransactionManager
ResourceManagers
CommunicationManager
Sessions
Autres TransactionManagers
Master Log
LogManager
Transactions actives
Page 17
© RJ Chevance
Validation à deux phases(3)
! Cas distribué (suite)
Ecriture (forcée) d'unenregistrement"Commit" dans le journal
Coordinateur(Transaction Manager)
Participants locaux(Resource Managers)
Prépare
Préparation locale
OK
Préparation locale
Commit
commitment local
Ack"Complete"Ecriture d'un enregistrement"Complétion" dans le journal
.Préparation "distribuée"
Participants distribués(Transactions Managers)
Préparation localePréparation "distribuée" Décision "Prépare" -> LogAcquitter
OK
Prépare
Décision
Commit
commitment distribué"Complete"Acquitter
Page 18
© RJ Chevance
Validation à deux phases(4)
! Cas distribué (suite)Transaction Manager "Coordinateur":
Commit
. Préparation locale :"prépare" envoyé à chaque RMlocal. Préparation "distribuée" : "prépare" envoyé à chacunedes sessions impliquées dans la transaction (en fait desTMs). Décision : Si tous les RM locaux et les sessionsimpliquées répondent OK, écriture d'un enregistrement"commit" avec toutes ces informations dans le journal). Commit : Envoi de l'ordre "commit" à tous les RMlocaux et aux TM des sessions concernées. "Complète" : Si tous les RM locaux et les toutes lessessions impliquées (les TMs) répondent positivementécriture (forcée) d'un enregistrement "complétion" dans le journal. Après la fin d'écriture, mise à jour de l'état dela transaction ("finie")
Abort
. "Broadcast Abort" : envoyer le message "abort" àtoutes les sessions concernées. Défaire : défaire la transaction à l'aide des informationsdu journal. "Complète" : Ecriture d'un enregistrement dans lejournal et mise à jour de l'état de la transaction
OO
Transaction Manager "Participant":
Prépare()
. Préparation locale :"prépare" envoyé à chaque RM local
. Préparation "distribuée" : "prépare" envoyé à chacune des sessions impliquées dans la transaction (en fait des TMs)
•. Décision : Si tous les RM locaux et les sessionsimpliquées répondent OK, le TM est quasi prêt• Préparé : écriture d'un enregistrement "commit » avec les informations (RMs et TMs participantsainsi que le TM "parent" dans le journal)
. Réponse : répondre positivement au demandeur
. Attente : attente d'un ordre "commit" en provenance du coordinateur.
Commit()
. Commit : Envoi de l'ordre "commit" à tous les RM locauxet aux TM des sessions concernées. "Complète" : Si tous les RM locaux et les toutes les sessions impliquées (les TMs) répondent positivementécriture (forcée) d'un enregistrement "complétion" dans le journal. Après la fin d'écriture, mise à jour de l'état de la transaction ("phase 2 terminée"). Acquittement : après l'écriture dans le journal, envoyer un acquittement du commit au coordinateur et mettre à jour l'état (local) de la transaction
Page 19
© RJ Chevance
Exemple de moniteur transactionnel : Tuxedo
! Initialement développé par AT&T pour ses propres applicationstransactionnelles sous Unix, repris ensuite par USL (Unix SystemLaboratories), Novell et maintenant possession de BEA
! Début de commercialisation en 1989. Plusieurs milliers desystèmes installés
! Disponible sur un grand nombre de systèmes! Caractéristiques
" Conforme au modèle X/Open DTP (Distributed TransactionProcessing)
" 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 20
© RJ Chevance
Tuxedo! Architecture d'application
Tools, 4GL’sTools, 4GL’s
ApplicationsApplications
C, C++, COBOLC, C++, COBOL
TUXEDOSystemTUXEDOSystem Client-
ServerClient-Server
ATMIATMI
Mngmnt& AdminMngmnt& Admin
NameServerNameServer
ConnectivityConnectivityDistributedTransactionProcessing
DistributedTransactionProcessing
System-Level(Hardware, Operating System,
Network)
System-Level(Hardware, Operating System,
Network)
Resource Manager(s)Resource Manager(s)
ATMI : Application - Transaction Manager Interface
Page 21
© RJ Chevance
Tuxedo(2)
! Architecture - Cas centralisé
Client
/T LIB
Client
/T LIB
/T LIB
Function 1
RM LIB
/T LIB
Function 1
RM LIB>><<
ResourceManager
/T LIB
Function n
RM LIB>>
ResourceManager
SYSTEM /TBulletin Board
Transaction et Communication Manager
Page 22
© RJ Chevance
Tuxedo(3)
! Architecture - Cas distribué
HOST
Bridge
UNIX Server UNIX Server
Server /Host ServerBridge
Server
UnixClient
Unix Client
BBLBBL
DBBL
WS Client WS Client
WS Handler
TMTM
Bulletin Board
Unix Client
Bulletin Board
Page 23
© 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 lespropriétés transactionnelles (soumission et achèvementgarantis)
# Gestionnaire de ressources (RM) conforme à XA" Tuxedo System/TDomain
# Requêtes transactionnelles entre des domainesd'administration séparés de Tuxedo
Page 24
© 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 parles SGBDs. Ceci est appelé "TP Lite" ou transactionnelléger
" Utilisation d'un moniteur transactionnel qui fournit le cadrearchitectural des applications et utilisation des servicesfournis 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émentsrentrent 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 deperformance,...
" Pour TP Heavy: limitation potentielle dans les progiciels que l'onpeut intégrer, pérennité du moniteur, complexité de laprogrammation,....
Page 25
© 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