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)