Contrôle de la réplication dans les SGBD temps réel distribués

41 Prépublication n 13 Fascicule n 2 Contrôle de la réplication dans les SGBD temps réel distribués Anis Haj Said, Laurent Amanton, Bruno Sadeg Laboratoire d Informatique, de Traitement de l Information et des Systèmes (LITIS) Université du Havre anis.haj-said@univ-lehavre.fr, laurent.amanton@univ-lehavre.fr, bruno.sadeg@univ-lehavre.fr Béchir Ayeb Pôle de Recherche en Informatique du Centre (PRINCE) Université de Monastir bechir.ayeb@fsm.rnu.tn Résumé : La réplication des données représente une alternative intéressante pour les systèmes de gestion de bases de données temps réel distribués (SGBDTRD) puisque la disponibilité des données sur plusieurs sites pourrait augmenter les chances de respecter les échéances des transactions. Cependant, ces systèmes doivent assurer la mise à jour et la cohérence des différentes copies des données. Afin de satisfaire ces exigences, les SGBDTRD doivent implémenter des protocoles de contrôle de réplication adaptés. Dans ce papier, nous discutons de l intérêt de répliquer les données dans les SGBDTRD et nous présentons RT-RCP, un protocole de contrôle de réplication que nous avons conçu pour gérer la réplication des données dans un contexte temps réel. Le défi est d assurer la mise à jour des copies sans pour autant affecter le respect des échéances des transactions. Pour cela, RT-RCP tolère l apparition d incohérences entre les copies tout en empêchant les accès aux données non-fraîches. Mots-clés : base de données, temps réel, réplication, protocole de réplication, transaction. 1 Introduction Les SGBDTR sont utilisés essentiellement pour gérer les données dans les systèmes temps réel (STR), puisque les base de données classiques ne sont pas en mesure de garantir la prévisibilité et le respect des contraintes temporelles de ces systèmes [1, 2]. Les STR étant généralement distribués [2], la gestion des données dans ces systèmes nécessite des systèmes de gestion de base de données temps réel distribués (SGBDTRD). Anis Haj Said, Laurent Amanton, Bruno Sadeg, Béchir Ayeb «Contrôle de la réplication dans les SGBD temps réel distribués»

42 La réplication des données est utilisée dans les SGBD distribués afin d augmenter la disponibilité des données permettant aux transactions de s exécuter sur n importe quel site du système et ainsi diminuer le temps de réponse des transactions. Cet aspect peut favoriser le respect des contraintes temporelles des transactions dans les SGBDTRD. En effet, la réplication des données permet de mieux distribuer la charge du système sur tous les sites permettant une exécution plus rapide des transactions et favorisant ainsi le respect des échéances temporelles des transactions. La réplication des données répond aux exigences des applications temps réel puisque ces dernières présentent souvent des contraintes temporelles sur le temps d accès aux données aussi bien que l accès à des données à durées de validité. Cependant, l utilisation de la réplication des données nous amène à être vigilant par rapport à la cohérence de la base. En effet, permettre aux transactions de manipuler plusieurs copies d une même donnée peut générer des incohérences [3]. Plusieurs recherches ont été dédiées au domaine de la réplication des données dans les systèmes de base de données distribués et ont proposé plusieurs protocoles de contrôle de réplication appliqués à différentes architectures de systèmes. On distingue deux principaux modèles pour ces protocoles. Le modèle de réplication synchrone [4] et le modèle de réplication asynchrone [5]. Dans le premier modèle, une transaction doit se synchroniser avec toutes les copies qu elle modifie avant validation. Alors qu avec le deuxième modèle, les modifications introduites par une transaction sont propagées aux autres sites seulement après validation de la transaction. On distingue aussi deux architectures principales qui déterminent l emplacement de l exécution de la transaction [6]. La première est l architecture primary copy dans laquelle chaque donnée possède une copie primaire dans un site spécifique (serveur). Les transactions sont seulement exécutées sur les serveurs des données qu elles manipulent et les mises à jour sont envoyées aux autres copies sur les autres sites. Dans la deuxième architecture, update everywhere, les transactions peuvent être exécutées sur n importe quel site du système et toutes les copies des données modifiées sont mises à jour ultérieurement. D autres études se sont intéressées à la réplication des données dans les SGBDTRD [7, 8, 9]. Ces études prennent en compte l aspect temps réel des transactions et des données. Les approches de réplication présentées dans ces études proposent d utiliser soit l architecture primary copy pour mettre à jour les réplicas d une manière déterministe [7] soit les protocoles de contrôle de concurrence adaptés avec des protocoles de validation distribués pour la sérialisation des mises à jour [9] ou encore des critères de similarité tels que l.pdfilon-sérialisabilité afin de tolérer des incertitudes dans les valeurs des copies [8]. Dans [7], Wei et al. proposent le protocole de réplication ORDER (On-demand Real-Time Decentralized Replication) dans lequel les mises à jour des réplicas sont faites par le primary copy périodiquement. Les périodes varient selon les besoins des transactions temps réel et la charge du système. L incovénient des protocoles de mises à jour à la demande est le temps nécessaire pour mettre à jour une donnée obsolète. En effet, les transactions temps réel, une fois lancées, sont obligées d attendre les mises à jour des données non fraîches nécessaires, ce qui peut provoquer le dépassement de leur échéance. En plus, en cas de surcharge du système, un site primary copy devient un goulet d étranglement [10, 3]. Xiong et al. proposent MIRROR (Managing Isolation in Replicated Real Time Object Repositories) [9], qui est un protocole de contrôle de concurrence pour les SGBDTR répliqués, qui intègre au protocole O2PL [11] un méchanisme qui détermine les priorités des transactions selon leur état d exécution afin d améliorer les performances du SGBDTR. L.pdfilon-sérialisabilité est une autre approche proposée par Son et al. [8]. Elle consiste à tolérer des imprécisions limitées dans les valeurs des données utilisées par les transactions

43 temps réel. Dans cette approche, la cohérence de la base est sacrifiée en faveur du respect des contraintes temporelles. Le reste du papier est organisé comme suit. Dans la deuxième section, nous proposons nos modèles et les hypothèses que l on pose pour notre SGBDTRD. Puis, dans la section 3, nous discutons de la contribution de la réplication des données dans les SGBDTRD. Ensuite, nous présentons RT-RCP, un protocole de contrôle de réplication que nous avons conçu pour les SGBDTRD (cf. section 4). Enfin, nous concluons par une discussion sur le protocole RT-RCP et les perspectives que nous donnons à notre travail. 2 Modèles et hypothèses 2.1 Modèle des données Les applications temps réel manipulent des données temporelles auxquelles sont associés des intervalles de validité, dans lesquels les valeurs de ces données sont utilisables. Ces données deviennent non-fraîches une fois que la borne supérieure de l intervalle est dépassée sans qu elles ne soient mises à jour. Ces données sont mises à jour par des transactions de mise à jour et sont également appelées données variantes. De plus, les applications temps réel manipulent des données invariantes, qui dénotent celles dont les valeurs ne changent pas au cours du temps. En d autres termes, l intervalle de validité des données invariantes est infini. Un sous ensemble des données invariantes est utilisé par des transactions temps réel. On dénote par D l ensemble des données de la base. Certaines données de l ensemble D sont plus critiques pour le fonctionnement du système que d autres. On dénote l ensemble des données critiques par D critique. Cet ensemble comporte l ensemble des données variantes et une partie des données invariantes puisqu elles sont manipulées par des transactions temps réel. Ainsi, on définit deux sous-ensembles de données critiques qui sont Dcritique var et Dinvar critique. Les autres données de la base sont utilisées seulement par des transactions non temps réel et ne sont donc pas critiques pour le système. On dénote l ensemble de ces données par D non critique. Généralement, D non critique représente la majeure partie des données dans un SGBDTR. Ce modèle a été adopté dans [12]. 2.2 Modèle du système Nous proposons un modèle de système dans lequel les données de D critique sont totalement répliquées. Chaque site contient une copie de chaque donnée de D critique. Chaque site dans le système possède des listes associées à chaque donnée de D invar critique. Dans chaque liste relative à une donnée critique invariante se trouvent les sites dans lesquels ses copies sont fraîches. En d autres termes, ce sont des listes des copies disponibles de chaque donnée dans Dcritique invar. On dénote chaque liste associée à une donnée par LAC (List of Available Copies). 2.3 Modèle des transactions Dans notre modèle, nous considérons que le SGBDTRD exécute des transactions temps réel et des transactions non temps réel. En plus, pour les transactions temps réel, nous considérons seulement les transactions strictes et non-critiques (firm-transactions) [13], qui, lorsqu elles dépassent leur échéance deviennent inutiles pour le système et sont abandonnées.

44 2.4 Hypothèses Dans cet article, nous considérons un SGBDTRD qui consiste en un ensemble de bases de données résidentes en mémoire principale, connectées à un réseau haut-débit. Nous supposons également que le temps de transmission de chaque message par le réseau est prévisible. En plus, les messages envoyés par un site sont délivrés selon leur ordre d émission (FIFO). 3 La réplication des données dans les bases de données temps réel distribuées La réplication des données est souvent utilisée dans les systèmes de bases de données distribués afin d augmenter la disponibilité et faciliter l accès aux données. Ainsi, la performance, la fiabilité et la disponibilité de tels systèmes peuvent être améliorées considérablement à travers la réplication des données. Certaines données de la base sont plus critiques que d autres pour le fonctionnement du système (cf. 2.1). En se basant sur cette propriété, un protocole de contrôle de réplication approprié pour les SGBDTRD doit tenir compte des caractéristiques des données et de leur importance pour le système. Le protocole de réplication doit assurer la disponibilité et l accessibilité des données critiques afin de permettre au système d accomplir ses tâches principales, et d améliorer ainsi sa performance qui est le ratio des transactions qui respectent leur échéance. La manipulation de plusieurs copies d une donnée peut engendrer l apparition d incohérences entre les copies. Les protocoles de réplication doivent garantir la cohérence des copies afin d éviter l utilisation des copies non-fraîches par des transactions. L idée la plus simple consiste à adopter un modèle de réplication synchrone qui assure la cohérence des copies. Cependant, l utilisation de ce modèle peut augmenter considérablement la probabilité de blocage et par conséquent le nombre de transactions abandonnées. En effet, avec le modèle de réplication synchrone, une transaction ne peut être validée qu après propagation des mises à jour à toutes les copies des données modifiées. Ainsi, la durée de la phase de validation de la transaction augmente en fonction du nombre de données et de sites intervenant dans l exécution de la transaction. Cette contrainte accroît la probabilité que la transaction rate son échéance. Par conséquent, ce modèle ne convient pas pour la mise à jour des réplicas des données dans D invar critique. Le modèle asynchrone, où les modifications effectuées par les transactions sont propagées aux autres sites après validation, est souvent utilisé dans plusieurs systèmes de bases de données commerciaux. La mise à jour asynchrone a pour effet de diminuer la charge du système, par contre des incohérences parmi les copies peuvent survenir. Cette caractéristique ne signifie pas que la cohérence de la base n est pas importante. Il est bien connu des utilisateurs et des développeurs que la résolution des incohérences créées par le modèle asynchrone peut être coûteuse et compliquée. En effet, afin de résoudre ce problème et ramener la base dans un état cohérent, les systèmes de bases de données utilisent des protocoles de réconciliation basée sur des techniques d estampillage. Le protocole de réconciliation provoque l annulation puis le redémarrage des transactions ayant utilisé des données non-fraîches. Ce problème rend le modèle asynchrone inadéquat pour les SGBDTRD, puisque l annulation et le redémarrage des transactions peut affecter considérablement les performances du système. L inconvénient de ces deux modèles est que chaque site du système ne possède aucune information particulière sur l état de la base localisée sur les autres sites du système distribué. En effet, pour le modèle asynchrone, les transactions sont exécutées localement sans se soucier de l état des copies des données utilisées. Les incohérences sont détectées

45 après l achèvement de l exécution de la transaction. Alors que pour le modèle synchrone, les transactions sont forcées de mettre à jour toutes les copies des données impliquées avant validation pour s assurer qu elles ont la même valeur. Puisque les données dans les SGBDTRD ont des caractéristiques différentes, nous estimons qu un protocole de contrôle de réplication adapté aux données de l ensemble Dcritique invar ne l est pas forcément pour les données de l ensemble Dvar critique. Dans le paragraphe suivant, nous présentons le protocole RT-RCP (Real Time Replication Control Protocol) afin de gérer les réplicas des données dans l ensemble Dcritique invar. RT-RCP autorise l apparition d incohérences entre les copies des données, tout en empêchant les accès à ces données jusqu à leur mise à jour. 4 Le protocole RT-RCP Les données dans l ensemble Dcritique invar sont utilisées par des transactions temps réel qui doivent s exécuter avant qu elles ne dépassent leur échéance. Puisque généralement la plupart des opérations exécutées par les transactions sont des opérations de lecture, la disponibilité des données sur les différents sites du réseau distribué peut augmenter considérablement la probabilité que ces transactions respectent leur échéance. Dans notre modèle, les données dans l ensemble Dcritique invar sont totalement répliquées, ce qui permet aux transactions d accéder aux données sur n importe quel site. Répliquer les données sur tous les sites nous amène à être vigilant par rapport à la cohérence des copies des données critiques. En effet, quand une transaction modifie une donnée, ses copies doivent être mises à jour en même temps ou bien suspendues d accès jusqu à leur mise à jour. Autrement, il y aura un risque que d autres transactions utilisent des données obsolètes. Puisque le temps nécessaire à la transmission d un message est prévisible, un site peut estimer le nombre de mises à jour qu il peut exécuter tout en respectant l échéance de la transaction. En effet, si le temps disponible avant la validation est supérieur au temps maximum de transmission des informations de validation, alors la synchronisation des données est réalisée immédiatement, sinon elle est différée pour être effectuée de manière asynchrone. Pour chaque site distant, on envoie la liste des données à mettre à jour ainsi que les nouvelles valeurs. Cet envoi est effectué que si le temps de transmission de ces données est plus court que le temps restant avant validation, sachant que le temps de mise à jour proprement dit reste négligeable devant le temps de communication. L idée principale de notre protocole est d utiliser une approche mixte afin de mettre à jour les copies des données dans l ensemble Dcritique invar. En fait, avec RT-RCP, un site qui exécute une transaction met à jour d une manière synchrone autant de copies que possible avant validation et diffère les autres mises à jour après validation de la transaction. La figure 1 illustre le fonctionnement de RT-RCP afin de mettre à jour les copies des données qui sont utilisées par une transaction. Soit d une donnée dans l ensemble D invar critique manipulée par la transaction T qui s exécute sur le site 2. Lorsque la transaction T suscite un accès en écriture sur la donnée d, elle requiert des verrous en écriture sur la copie locale de d et sur ses copies. Ainsi, l accès à d et ses copies est suspendu jusqu à leur mise à jour. Durant la phase de validation, le site 2 met à jour deux copies de d et libère les verrous en écriture sur ces deux copies. Il ne peut pas faire plus car il doit assurer le respect de l échéance de la transaction. Après validation, le site 2 propage les modifications aux copies qui ne sont pas encore mises à jour et libère les verrous en écriture. D un coté, le protocole RT-RCP essaye de respecter les contraintes temporelles des transactions, et de l autre coté, il tente de rendre disponibles les copies des données

46 Fig. 1: Fonctionnement de RT-RCP. manipulées. Ce fonctionnement de RT-RCP comporte un inconvénient qui peut être décrit par la situation suivante : Soit T une transaction lancée sur le site 4 après les mises à jour synchrones propagées par la transaction T. Afin de distribuer l exécution de la transaction sur les différents sites du système, T est divisée en sous-transactions T 1,..., T n (1 < n N avec N le nombre de sites dans le système). Puisque les données dans l ensemble Dcritique invar sont répliquées sur tous les sites et puisque les sites ne possèdent aucune information sur l état de la base de donnée dans les autres sites, les sous-transactions de T sont envoyées aléatoirement aux sites participants. Soit T i (1 i n) une sous-transaction lancée sur le site k (1 < k n) qui veut accéder à la donnée d. Deux cas peuvent se produire : La copie de la donnée d sur le site k est fraîche et ainsi la sous-transaction T i sera exécutée normalement ; La copie de d n est pas encore mise à jour et dans ce cas la sous-transaction T i sera bloquée jusqu a ce que le site k reçoive la nouvelle valeur de d et libère le verrou en écriture. Dans ce dernier cas, le blocage de la transaction T i peut provoquer le dépassement de son échéance et ainsi son abandon. Alors que T i aurait pu avoir une chance de s exécuter en respectant son échéance si elle avait été lancée sur un site où la donnée d est fraîche. L abandon de transactions affecte les performances des SGBDTRD et doit être évité autant que possible. Pour empêcher le deuxième cas de se produire, chaque site doit avoir des informations sur l état de la base de données sur les autres sites du système. Ces informations aident les sites à prendre des décisions adéquates lors du choix des sites participants à l exécution d une transaction. En associant des listes de copies disponibles (LAC) avec chaque donnée dans l ensemble Dcritique invar, un site peut lancer des sous-transactions sur les sites où les données désirées sont disponibles. Chaque site qui détient des verrous en écriture sur une donnée et ses copies doit mettre à jour chaque LAC relative à chaque copie de cette donnée. Étant le seul responsable de la propagation des mises à jour, le site détenteur des verrous en écriture est le seul à avoir des informations sur l état de chaque copie de la donnée verrouillée. Il informe ainsi les autres sites en joignant la liste LAC relative à cette donnée avec chaque message de mise à jour.

47 4.1 Mise à jour des listes LACs La mise à jour des LACs se fait en deux étapes. La première étape de mises à jour est jointe aux éventuelles mises à jour des copies des données modifiées lorsque la transaction entre dans sa phase de validation. La deuxième étape commence lorsque toutes les copies des données modifiées ont reçu les mises à jour. Ainsi, on établit une nouvelle étape d échange de messages pour la mise à jour des LACs. Les figures Fig. 2, Fig. 3, Fig. 4 et Fig. 5, illustrent les modifications des LACs au cours de l utilisation du protocole RT-RCP pour le même exemple que celui dans Fig. 1. Les LACs associées aux copies de la donnée d contiennent l ensemble des sites dans lesquels les copies de d sont à jour. Supposons qu initialement (Fig. 2) les copies de d sont fraîches sur tous les sites. Ainsi, chaque LAC comporte comme éléments les cinq sites du système. Afin de permettre à la transaction d exécuter des opérations d écriture sur d, le site 2 verrouille en écriture sa copie locale de d et demande les verrous en écriture sur les copies de d aux autres sites (Fig. 3).Chaque site envoie un message de confirmation au site 2 lorsque sa copie locale de d est verrouillée et modifie sa LAC pour ne contenir que le site 2. Quand les verrous sont détenus par le site 2, ce dernier se comporte comme une primary copy de la donnée d. Chaque transaction qui a besoin de la donnée d est automatiquement envoyée au site 2 pour y être exécutée. Pendant la phase de validation (Fig. 4), et puisque le temps nécessaire pour l envoi d un message est prévisible, le site 2 ne peut mettre à jour que les copies de d du site 1 et 4, sinon la transaction T risque de rater son échéance. Une nouvelle liste LAC est jointe au message de la mise à jour dans lequel figurent les trois sites où les copies de d seront à jour. Le but de l envoi des mises à jour avant la validation de la transaction est de mettre en disponibilité aussi rapidement que possible les copies de d. En effet, lorsque le site 2 détient les verrous en écriture sur d, il se comporte comme une primary copy de d et il devient ainsi un goulet d étranglement [10]. Après validation de la transaction (Fig. 5), le site 2 envoie les modifications aux sites qui n ont pas encore de mise à jour pour d et sa LAC. Le site 2 envoie d abord un message au site 5 contenant la mise à jour de la copie de d et une nouvelle liste LAC contenant les trois sites précédemment mis à jour en plus du site 5. De même, la liste LAC envoyée au site 3 contiendra les cinq sites du système. site 1 site 2 site 3 site 1 site 2 site 3 site 5 site 4 site 5 site 4 Fig. 2: État initial du système. Fig. 3: Demande de verrous. À ce stade du protocole RT-RCP, toutes les copies de d sont fraîches. Cependant, les LACs contiennent des informations différentes selon l ordre de réception de la mise à jour. Une fois la propagation des modifications achevée, le site 2 envoie une nouvelle LAC à chaque site du système contenant les cinq sites. L objectif du protocole RT-RCP est de mettre à jour les réplicas des données modifiées sans que cela n affecte les performances du système. RT-RCP répond aux exigences des transactions temps réel en garantissant le respect de leur échéance (la mise à jour des réplicas ne provoque pas le dépassement de l échéance de la transaction) et en rendant disponible à l accès autant de réplicas que possible. Cependant, le coût de l étape

48 site 1 site 2 site 3 site 1 {2,1,4,5,3} site 2 {2,1,4,5,3} site 3 site 5 site 4 {2,1,4,5} site 5 site 4 Fig. 4: Mises à jour synchrones. Fig. 5: Mises à jour différées. supplémentaire d échange de messages nécessaire à la mise à jour des LACs peut affecter les performances du système en cas de surcharge. Les simulations qu on envisage de faire nous permettront de conclure, selon le comportement du système, sur l efficacité de RT- RCP. 5 Conclusion et perspectives Le protocole RT-RCP trouve un compromis entre le respect des contraintes temporelles des transactions et la mise à jour des réplicas. En effet, RT-RCP ne se soucie pas de mettre à jour tous les réplicas d une manière synchrone. Il le fait tant que l échéance de la transaction peut être respectée et il diffère les mises à jour restantes après validation de la transaction. Comme résultat, on a un niveau de réplication dynamique des données qui varie selon la charge du système et les contraintes temporelles des transactions temps réel. RT-RCP assure l utilisation des données fraîches par les transactions temps réel. En effet, les sites se réfèrent aux listes LAC de chaque copie afin de faire un choix adéquat des participants à l exécution d une transaction. Puisque chaque LAC relative à une donnée est délivrée par le site qui détenait les verrous en écriture sur toutes les copies de cette donnée, alors les sites figurant dans une LAC ne peuvent contenir qu une copie fraîche de la donnée. Notons que le fonctionnement de ce protocole nécessite deux étapes d échanges de messages entre le site sur lequel s exécute la transaction et les autres sites du système distribué. Le coût de ces échanges pourrait alors être élevé en cas du surcharge du système. L une des perspectives de notre travail consiste d abord à tester notre protocole RT-RCP sur un simulateur développé dans notre équipe de recherche et ensuite de coupler ce protocole avec un système tolérant aux fautes se basant sur une architecture primary/backup. Références [1] K. Ramamritham. Real-Time Databases. Journal of Distributed and Parallel Databases, 1(2) :199 226, 1993. [2] K. Ramamritham, S.H. Son, and L.C. Dipippo. Real-Time Databases and Data Services. Real-Time Systems, 28 :179 215, 2004. [3] J. N. Gray, P. Holland, D. Shasha, and P. O Neil. The dangers of Replication and a Solution. In 1996 ACM SIGMOD on Management of Data, pages 173 182, Montreal, Canada, 1996. [4] P. A. Bernstein, V. Hadzilacos, and N. Goodman. Concurrency Control and Recovery in Database Systems. Addison-Wesley, 1987. [5] C. Pu and A. Leff. Replica Control in Distributed Systems : An Asynchronous Approach. In J. Clifford and R. King, editors, Proc. of the ACM SIGMOD on Management of Data, Denver, Colorado, pages 377 386. ACM Press, 1991. [6] J. Gray. The Benchmarks HandBook for DataBases and Transaction Processing Systems. Morgan Kaufmann, 1993.

49 [7] Y. Wei, A. A. Aslinger, S. H. Son, and J. A. Stankovic. Order : A Dynamic Replication Alogorithm for Periodic Transactions in Distributed Real-Time Databases. In 10 th International Conference on Real Time and Embedded Computing Systems and Applications (RTCSA 2004), 2004. [8] S. H. Son and F.Zhang. Real-Time Replication Control for Distributed Database Systems : Algorithms and Their Performance. In Proc. of the 4th Intl. Conf. DASFAA 95, Singapore, pages 214 221, 1995. [9] M. Xiong, K. Ramamritham, J. R. Haritsa, and J. A. Stankovic. Mirror : a State-Conscious Concurrency Control Protocol for Replicated Real-Time Databases. Inf. Syst., 27(4) :277 297, 2002. [10] M. Wiesmann, F. Pedone, A. Schiper, B. Kemme, and G. Alonso. Database Replication Techniques : A Three Parameter Classification. In Proceedings of 19th IEEE Symposium on Reliable Distributed Systems (SRDS2000), Nürenberg, Germany, 2000. IEEE Computer Society. [11] R. Abbott and H. Garcia-Molina. Scheduling Real-Time Transactions : A Performance Evaluation. In 14 th Int. Conf. on Very Large Data Bases (VLDB), pages 1 12, Los Angeles, California, March 1988. [12] L. Shu, J. Stankovic, and S. Son. Real-Time Logging and Failure Recovery. In In IEEE Real-Time Technology and Applications Symposium, 2002. [13] C. Duvallet, Z. Mammeri, and B. Sadeg. Les SGBD Temps Réel. Technique et Science Informatiques, 18(5) :479 517, 1999.