Limites du modele transactionnel strict

Dans certains cas, l'utilisation du modele transactionnel strict pose probleme. En eet, le respect des proprietes ACID des transactions peut aboutir a un blocage des applications de la carte a microprocesseur.

Dans cette section, nous allons donc, dans un premier temps, etudier une appli-cation pour laquelle se posent des problemes lors de l'utilisation d'un modele tran-sactionnel strict. Ensuite, nous proposerons une ebauche de solution a ce probleme, basee sur la prise en compte de la semantique des operations.

1.8.1 Le cas de l'application GSM-PME-CB

Commenous l'avons dit a plusieurs reprises,les cartes a microprocesseurcontiennent peu de donnees, mais ces donnees sont tres sensibles, et peuvent ^etre frequemment accedees de maniere concurrente.

Dans certains cas, un simple mecanisme de contr^ole de concurrence sura pour assurer la serialisation des transactions impliquees, mais il y a aussi des cas ou ces mecanismes conduirons systematiquement a une annulation de la transaction. Nous allons decrire ici le cas d'une application qui necessite un contr^ole de concurrence plus elabore qu'un simple contr^ole strict pour aboutir.

Prenons le cas d'une application distribuee, basee sur un reseau de communica-tion cellulaire, mettant en jeu les partenaires suivants:

{ L'utilisateur du telephone (c'est-a-dire de la carte SIM contenue dans ce tele-phone), qui dispose plusieurs services charges sur une carte a microprocesseur. { L'operateur de telephonie mobile, qui fournit un acces payant au reseau. Dans le cas de l'application decrite ici, le montant de la communication sera direc-tement preleve sur le PME du client12present dans la carte.

12:Dorenavant, les prestataires de services GSM fournissent tous des formules d'acces au reseau sans abonnement, bases sur le rechargement d'un compte type PME

1.8. LIMITESDUMOD 

ELETRANSACTIONNELSTRICT 103 { Un fournisseur de services, ou de biens, que l'utilisateur peut contacter pour

eectuer des achats au moyen du PME charge dans sa carte multi-services. Le deroulement de l'application qui pose probleme avec le modele transactionnel est le suivant:

{ Dans un premier temps, l'utilisateur ouvre une connexion sur le reseau. Les co^uts relatifs a cette connexion seront debites directement sur le PME present dans la carte a microprocesseur.

{ Une fois connecte au reseau, l'utilisateur desire acheter un objet (ou un ser-vice), en le payant avec son PME.

{ S'il ne reste plus assez d'argent sur le PME, l'utilisateur doit ^etre en mesure de contacter sa banque, pour recharger le PME avec son service((Carte Bancaire)). { Une fois le rechargement eectue, l'utilisateur peut poursuivre son achat, et

terminer sa connexion.

Il est impossible d'executer une telle application avec l'architecture que nous venons de decrire dans ce chapitre, car il y a de multiples acces simultanes sur le PME de la carte a microprocesseur.

Pourtant, ce type d'application va devenir courant dans les annees a venir, et devra ^etre gere facilement par le programmeur. Il convient donc de fournir un me-canisme (de type transactionnel), en orant une possibilite de serialisation des tran-sactions plus elevee sur certains types d'applications.

1.8.2 Problematique

Les methodes de contr^ole de concurrence les plus repandues ne permettent pas une forte serialisation des transactions. Dans le cas d'un PME sur une carte a mi-croprocesseur cela se revele problematique, car il est souvent le centre des ressources de la carte.

En cas de verrouillage du PME par une transaction, une partie non negligeable des services de la carte peut se retrouver bloquee, alors que les ressources necessaires sont encore presentes dans la carte13.

1.8.3 Prise en compte de la commutativite des operations

Une solution pour autoriser une plus grande serialisation des transactions est de prendre en compte la semantique des objets accedes

[CFR89]

, de maniere a etablir des proprietes de commutativite sur les actions typees14.

Il existe de regle de commutativite

[CFG94]

:

{

La commutativite en arriere:

dans le cas de modication directe du sup-port au cours de l'execution de la transaction, deux operations op1 et op2,

13:Il est dicilement concevable de bloquer un PME contenant 1000 FF pour une transaction portant sur 50 FF

executees par T1 et T2 (dans l'ordre T1:op1;T2:op2) commutent en arriere si, quelque soit l'etat initial de la base, l'execution dans l'ordre inverse (c'est a dire T2:op2;T1:op1) a le m^eme eet sur la base.

{

La commutativite en avant:

dans le cas ou la base n'est pas modiee tans que les transaction ne sont pas validees, deux operations op1et op2executees par T1 et T2, vont utiliser en entree le m^emeetat de la base. On peut dire que ces deux operations commutenten avant, si les deux executions (T1:op1;T2:op2 et T2:op2;T1:op1) ont le m^eme eet sur la base

Le modele que nous avons choisi pour les cartes a microprocesseur, dans le cas des cartes multi-services, consiste a utiliser un mecanisme de reprise sur panne base sur la journalisation des images avant des donnees. La mise a jour du support stable se fait donc au fur et a mesure de l'execution de la transaction.

Dans le cadre des PME, on peut reprendre les tables de commutativite pour les compteurs et pour les objets de type compte (avec les operations de debit et credit), qui ont deja ete etudiees

[B95]

(cf. Tableau III.1.3: les lignes representent l'operation de T1, et les colonnes l'operation de T2).

Credit(x,V2) Debit(x, v2, ok) Debit(x, v2, non)

Credit(x, v1)

Commute en avant OUI NON OUI Commute en arriere OUI OUI NON

Debit(x,v1,ok)

Commute en avant OUI OUI NON Commute en arriere OUI NON OUI

Debit(x,v1,non)

Commute en avant NON OUI OUI Commute en arriere NON OUI OUI

Tab.III.1.3 - commutativite des actions sur un compte [B95 ]

Avec l'utilisation d'un protocole de concurrence pessimiste, comme le protocole de verrouillage a deux phases, dans certains cas, on ne peut pas conna^tre le resultat de l'operation de la seconde transaction, avant de l'avoir executee. Dans le cas ou ces resultats sont indispensables (ici, dans le cas ou la deuxieme transaction eectue un debit) l'operation doit ^etre eectuee dans un espace de travail prive, pour pouvoir tester la commutativite.

Si on se contente de considerer la commutativiteen arriere, il y a encore beaucoup de scenario ou les actions ne commutentpas. Une nouvelle de commutativite,appelee en Avant-Arriere permet d'ameliorer cela

[GFP95]

.

Une telle prise en compte de la semantique de l'objet accede rend possible l'ap-plication decrite precedemment, car les con its se trouvent reduits.

1.9. D 

EBORDEMENTDESDONN  EES  AL'EXT  ERIEURDELACARTE 105

1.9 Debordement des donnees a l'exterieur de la

Dans le document COST-STIC Cartes Orientées Services Transactionnels et Systèmes Transactionnels Intégrant des Cartes (Page 116-119)