données, mais aussi pour permettre la détection de conflits lors d’accès multiples par plusieurs transactions. D’autres TMs considèrent une gra- nularité plus fine comme le mot mémoire (word).
3.2.3 Faible et forte isolation
Blundell et al. (2005) ont introduit les termes d’atomicité faible et forte. La forte atomicité garantit une séparation d’actions et de sémantique entre le code transactionnel et non-transactionnel. Cependant, ces termes sont uti- lisés dans Larus et Rajwar (2007) sous d’autres appellations, car considérés non-appropriés à la véritable signification de l’isolation. Ainsi, le terme isolation faible signifie qu’un conflit de référence mémoire se trouvant en dehors de la transaction ne doit pas suivre les protocoles du système de TM.
3.3 Gestion des conflits
Les transactions s’exécutant d’une manière concurrente, ont besoin de se synchroniser à la fois pour les types de mises à jour d’objets directe et différée. Dans une mise à jour directe les objets peuvent être modifiés dès que les transactions y apportent des changements, ce qui n’est pas le cas dans le mode différé, où il faut attendre la phase de validation (commit) de la transaction manipulatrice pour une éventuelle mise à jour.
Détection des conflits
Un conflit entre deux transactions apparaît sur un objet donné quand celui-ci est manipulé par des opérations de lecture/écriture. Au moins une des transactions doit modifier l’objet en écriture dans la mesure où les opérations de lecture ne peuvent pas provoquer de conflit entre elles. Lorsqu’un un conflit apparaît, le système de gestion de conflit d’une mé- moire transactionnelle doit être capable de déterminer quelles sont les opérations qui sont en conflit. La détection suivant les deux cas de mise à jour présentés plus haut, se fait soit d’une manière directe ou différée.
Types de conflits
Une fois le conflit détecté, la résolution se fait suivant la nature de la détection (directe/différée). Scott (2006) a classé les différents types de résolution de conflits et il distingue quatre types :
– Invalidation lazy. Les transactions TA et TB sont en conflit si TA écrit un objet, TB lit le même objet, et TAest validée avant TB.
– Eager Écriture-Lecture E-L. Les transactions TAet TB sont en conflit si TA et TB ont un conflit de type lazy, ou bien, TA écrit un objet et TB lit par la suite le même objet, et qu’aucune de ces transactions n’est entrée en validation.
– Invalidation mixée. Les transactions TA et TB sont en conflit si TA et TB ont un conflit de type lazy, ou bien, TA écrit un objet et TB lit et écrit par la suite le même objet, et qu’aucune de ces transactions n’est entrée en validation.
– Invalidation Eager. Les transactions TAet TBsont en conflit si TAet TB ont un conflit de type Eager E-L, ou bien, TB lit un objet et TA écrit par la suite le même objet, et qu’aucune de ces transactions n’est entrée en validation.
3.3.1 Gestionnaire de contention
Dans les mémoires transactionnelles, le conflit entre deux transactions peut se résoudre en annulant l’une d’elles. Le gestionnaire de contention est typiquement sollicité par certaines TM lors de l’apparition de conflits. Plusieurs politiques sont implémentées au sein du gestionnaire de conten- tion. Le choix d’une de ces politiques peut avoir une influence directe sur les performances du système. Malgré le fait que ces politiques ne garan- tissent pas toutes l’équité du système, leur stratégie commune tend tou- tefois à maximiser le facteur de progression des transactions par unité de temps. Scherer et Scott (2005) ont montré qu’il n’existe pas de politique pour un gestionnaire de contention plus performante que d’autres. Une hiérarchisation du gestionnaire de contention a été proposée par Guer- raoui et al. (2005) sous le nom de polymorphe et classent les gestionnaires de contention par facteur de leur charge dans le système.
Les politiques utilisées par le gestionnaire de contention annulent des transactions en vue de régler le conflit, mais ne garantissent pas quand ces transactions vont être relancées. Ce problème a été traité par Yoo et Lee (2008) en proposant un ordonnanceur des transactions basé sur une approche adaptative afin de déterminer d’une manière précise les instants de relance des transactions qui, auparavant avaient été abandonnées. Cette politique d’ordonnancement diffère donc des différentes stratégies utili- sées par le gestionnaire de contention présentées ci-après (Scherer et Scott 2005).
Polite
Une transaction essayant de détenir un objet se met en attente pendant un laps de temps limité et prédéterminé. Ces laps de temps appelés fenêtres de contention, vont d’abord croître exponentiellement avant d’annuler la transaction détentrice de l’objet. La vérification quant à la disponibilité de l’objet s’effectue avant chaque régénération de la fenêtre de contention. Karma
La plus haute priorité est attribuée à une transaction ayant en possession le plus d’objets. Une transaction de plus grande priorité peut directement annuler une autre transaction de moindre priorité si cette dernière dé- tient des objets en conflit avec la première. Pour une transaction ayant une priorité N fois plus faible, elle doit réitèrer N fois sur les objets avant de pouvoir annuler la transaction de plus haute priorité.
Eruption
Cette politique est similaire à Karma, sauf que la transaction de plus haute priorité est encore rehaussée en y ajoutant la priorité de la transaction de