Middleware transactionnel

Transcription

Middleware transactionnel
extension des moniteurs transactionnels
« anciens » (CICS d ’IBM par exemple) à la
gestion de transactions réparties
hétérogènes
implantation du modèle DTP (Distributed
Transaction Processing) de X/Open
TUXEDO (BEA), CICS (IBM), ENCINA
(Transarc), TopEnd (Nixdorf, ATT)
Celles d ’un middleware de données en
environnement multi-serveurs
équilibrage de charge
administration centralisée des systèmes
gestion répartie des transactions :
si SGBD homogènes (même vendeur) : peut être
assurée directement par ces SGBD
si SGBD hétérogènes : besoin de standardiser les
interfaces du protocole de validation 2 phases
Programme accédant et/ou modifiant des
données persistantes (fichier ou BD)
avec propriétés :
A : atomicité (tout ou rien)
C : cohérence (respect des contraintes définies
sur les données)
I : isolation (garantie de non interférence entre
des transactions s ’exécutant concurremment)
D : durabilité (état produit par la transaction ne
peut être perdu)
Transaction réservation(date, nbplace)
select reste into r from RESERVATION where dateresa=:date
si (r >= nbplace) alors
update RESERVATION set reste=reste-nbplace where
panne
dateresa=:date
éditer-place(date, nbplace)
valider transaction
sinon
imprimer ‘ réservation impossible ’
annuler transaction
finsi
Fin transaction
Transaction centralisée : toutes les
opérations d ’accès et de maj aux données
persistantes ont lieu sur le même site (et le
même système)
Transaction répartie : les opérations d ’accès
et/ou de maj aux données ont lieu sur au
moins deux sites
!
Agence de voyage
Réserver un voyage (transaction globale)
Réserver
avion
Réserver
hôtel
Réserver Transactions
voiture locales
"
#!$%&! '
Composition de transactions n ’est pas
atomique
atomicité d ’une transaction répartie doit
être assurée par un protocole de
synchronisation des sites impliqués dans
la transaction (protocole de validation à
deux phases ou V2P)
les SGBD commerciaux implantent une
version propriétaire du V2P
)
#!
)
moniteurs transactionnels ouverts
implantent DTP
tout SGBD supportant l ’interface XA peut
être piloté par un moniteur transactionnel
(plupart des SGBD commerciaux)
XA et TX ne gère que l ’aspect
transactionnel (début et fin de la
transaction, démarrage d ’un nouveau site,
…)
repris par OTS (Corba) et JTS (Java)
Application
program
Interface
native (SQL,…)
Resource
manager
Interface XA
#!
Interface TX
Transaction
manager
(
+
,
Participant 1
Début T1
+
,
Avantages :
Participant 2
assure l ’atomicité globale
beaucoup d ’implantations
Inconvénients :
prepare
OK (not OK)
OK
-
coordinateur
Début T2
prepare
Commit (abort)
*
OK (not OK)
décision
Commit (abort)
OK
performances (beaucoup de messages
échangés)
blocage (site reste bloqué depuis la fin de la
transaction locale jusqu ’au prepare)
sensibilité aux pannes
difficile à mettre en oeuvre sur Internet
#
. /
Transaction = séquence d’invocations url
(gestion du contexte par le web?)
Transaction = propriétés ACID (assurées par
le SGBD)
HTTP = pas de support de session
gérer le contexte côté client (cookies)
simuler des sessions http (web transactionnel)
#
0 12
Contexte est géré chez le client (cookies)
avantages :
simplicité de la mise en œuvre
accès en maj de la BD se fait en une fois à la fin (pas de
ressources bloquées)
si pas de terminaison de la transaction par l ’utilisateur,
rien à faire
#
0
Client browser
cgi
Serveur http
1
1
1’ c1
2 c1
2’ c1, c2
3 fin c1, c2
5’ del(c1, c2)
1’ c1
2 c1
2’ c1, c2
3 fin c1, c2
5’ del(c1, c2)
4’ ok
1 : premier accès
4 sql(c1, c2)
1’ : retour du cookie c1
2 : autre accès avec transport du cookie c1
2’ : retour des cookies c1, c2
3 : fin transaction avec transport c1, c2
4 : construction de la transaction et exécution sur le SGBD
5’ : suppression des cookies
SGBD
#
0 12
Inconvénients
pas vraiment transactionnel
fonctionnalité limitée
beaucoup de cgi à écrire (sauf programme de maj
générique qui prenne une séquence d ’instructions
SQL en entrée)
Problèmes des cookies
global à l ’utilisateur (pas de différenciation entre
fenêtres)
global à une url (pas deux transactions en même
temps sur le même site)
!
!
Client browser
Serveur http cgi
démon
passerelle
SGBD
!
Avantages
vraiment transactionnel
solution générique
Inconvénients
architecture complexe
blocage des ressources
nécessité de détecter un « abandon » de l ’utilisateur
(timeout)
pas très adapté sur Internet (plutôt cookies)
Contexte géré par un démon côté serveur
besoin d ’un identifiant de transaction stocké
côté client (cookie ou variable selon client) et
côté démon (dans une table)
passerelle ne traite pas une seule requête
mais toute une transaction (plusieurs
requêtes)

Documents pareils