EP1145121A2 - Procede de transmission asynchrone d'informations, possedant les proprietes acid - Google Patents

Procede de transmission asynchrone d'informations, possedant les proprietes acid

Info

Publication number
EP1145121A2
EP1145121A2 EP00958660A EP00958660A EP1145121A2 EP 1145121 A2 EP1145121 A2 EP 1145121A2 EP 00958660 A EP00958660 A EP 00958660A EP 00958660 A EP00958660 A EP 00958660A EP 1145121 A2 EP1145121 A2 EP 1145121A2
Authority
EP
European Patent Office
Prior art keywords
transaction
information
chain
communication channel
supplier
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP00958660A
Other languages
German (de)
English (en)
Other versions
EP1145121A3 (fr
Inventor
Michel Ruffin
Laurent Clevy
Simone Sedillot
Ramzi Karoui
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alcatel Lucent SAS
Original Assignee
Alcatel CIT SA
Alcatel SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alcatel CIT SA, Alcatel SA filed Critical Alcatel CIT SA
Publication of EP1145121A2 publication Critical patent/EP1145121A2/fr
Publication of EP1145121A3 publication Critical patent/EP1145121A3/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/466—Transaction processing

Definitions

  • the invention relates to the field of information transmission between suppliers and consumers through a chain of communication channels. More particularly, the invention consists in carrying out this transmission asynchronously while respecting the so-called ACID properties.
  • An asynchronous communication service includes a manager and one or more communication channels.
  • a supplier (customer of the service) transmits the information by addressing a specific channel.
  • the channel transfers information to the consumer
  • the channel acts as an intermediary between two customers by decoupling the transmission of information on one side and the other. We must be able to deliver information reliably while maintaining desynchronization between suppliers and consumers.
  • a known solution for transmitting data reliably is based on transaction systems.
  • a transaction is initiated by the data provider, then is "propagated" to intermediate elements (communication channels) to finally reach the consumer. Once the data has been delivered, and before confirming the modifications made (data delivery), the properties linked to the execution of the transaction are checked.
  • Asynchronous communication channels imply a desynchronization between suppliers and consumers while transactions require synchronization to enable end-to-end tracking of transaction stability properties.
  • a transaction must satisfy four properties grouped under the acronym ACID meaning: Atomicity, Coherence, Insulation and Durability. These four properties are closely related. The competition control and takeover mechanisms implemented by a transactional engine aim to enforce them.
  • the atomicity guarantees that either all of the updates to a transaction are made, or none of these updates are made. Failure to comply with this property can lead to all the data evolving from the initial coherent state to an incoherent state.
  • any series of actions constituting a transaction is marked by a beginning and an end.
  • the start of a transaction signals the transaction start event to the transaction engine.
  • Two orders are provided to mark the end of a transaction:
  • the consistency property concerns the semantic consistency of a data set.
  • the maintenance of this can be partly ensured by the mechanisms ensuring the control of integrity constraints and by the maintenance of the ownership of the transactions.
  • Isolation is essential in a multitasking environment, to ensure that each transaction sees a consistent state of all of the data. Isolation consists in ensuring that if the transaction is executed in parallel with other transactions (accessing a common set of data), there is a serial execution of the same transactions which would produce the same changes to the data set accessed by transactions. In this case, the isolation property is checked for this set of transactions.
  • Durability ensures that updates to a committed transaction are final.
  • the only action which must make it possible to undo the updates of a validated transaction is the execution of a compensation transaction. This property goes hand in hand with the atomicity property stipulating that the updates of a transaction form a coherent whole which is either abandoned as a whole, or validated durably.
  • a method of implementation in the event of memory or disk failure resulting in the loss of part of the information in the database, consists of having a recovery mechanism to recover the lost information.
  • a transaction can be initiated and guarantee from the information provider to the consumer that the ACID properties are respected.
  • the actions guaranteeing these properties must interact with each other in a reliable and determined manner, depending on the quality of service desired.
  • the object of the invention is therefore to provide an asynchronous communication system having ACID properties.
  • the subject of the invention is a method of asynchronous transmission of information between a supplier and a consumer, in accordance with the ACID properties, the supplier and the consumer being connected by a chain of communication channels.
  • This process is characterized in that the information is transmitted by means of established independent transactions:
  • Another subject of the invention is a communication channel, allowing the asynchronous transmission of information between a supplier and a consumer, in accordance with the ACID properties.
  • This channel has a set of customers, which can be other communication channels and / or consumers and it is characterized in that it comprises:
  • the supplier initiates a transaction only with the first communication channel in the chain. Also, he will very quickly obtain the result (“commit” or “Abort”) of this transaction, and will not remain blocked while awaiting the delivery of information to the consumer. In other words, the objective of asynchronous transmission is achieved.
  • Figure 1 shows the general principle of a transaction chain according to the invention.
  • FIG. 2 shows an example of a communication network implementing communication channels according to the invention.
  • a transaction is initiated by a supplier, referenced 1, destined for a communication channel 2.
  • This transaction includes at least the information that the supplier wishes to transmit to consumers 5.
  • the communication channel then stores this information in a reliable memory 4.
  • this reliable memory can be a database having an XA interface and the necessary recovery mechanisms.
  • the transaction which was initiated by the supplier 1 is finalized. If this finalization is successful (which conventionally corresponds to the sending of a "commit" message to the supplier), the information contained in the transaction is stored in queues 6.
  • a client of the channel can be a consumer as is the case in this example, or another communication channel. In the example in FIG. 1, there are therefore two queues, each one being associated with one of the two consumers 5.
  • the information is stored in the queues before finalizing the transaction, but it is only made available (for example by means of an availability identifier associated with each queue) when this finalization has been successful.
  • an execution thread exists for each consumer virtually connected to the channel.
  • the role of these execution threads is to consume the information stored in the queues 6 in order to initiate transactions with the clients of the communication channel.
  • These customers can be consumers 5, or possibly other communication channels.
  • These transactions contain the information stored in the queues, which was previously received from provider 1. Information is thus transmitted along the chain.
  • the reliable storage is never used in reading.
  • the reliable memory is typically a database, it is understood that any access is penalizing in terms of speed of execution. This method therefore makes it possible to minimize access to reliable memory, by the use of much faster queues, and consequently to accelerate the speed of transmission of information from the supplier to consumers.
  • each software element provides a standard recovery interface for failure recovery.
  • This interface allows you to undo the actions made by a failed transaction.
  • the reliable memory provides an interface which makes it possible mainly to remove information relating to a transaction from storage. Thus, if one of the transactions in the chain fails, all of the actions taken on the objects involved in the transaction in question are undone. Once the actions are undone due to the failure of a transaction, the transaction can be started again. by reading the information stored in the reliable memory.
  • This solution provides an end-to-end data recovery mechanism, working automatically with an external transaction system. Compared to other solutions, this mechanism is generic.
  • a single communication channel is considered, but this mechanism being symmetrical it works in the same way in any chain of channels.
  • the number of communication channels between the supplier and the consumer or consumers can be arbitrary.
  • a communication channel can connect as a client of another communication channel.
  • FIG. 2 illustrates an example of a network of communication channels.
  • a supplier F is connected to a first communication channel.
  • a supplier F 2 is connected to a second communication channel. These two communication channels have a third communication channel for the client.
  • One or more consumers C are connected as customers of the first communication channel, while one or more consumers C 2 are connected as customers of the second communication channel.
  • Such a network topology is of great practical interest. It allows consumers C to receive only information from the supplier F 17 while consumers C 2 receive information from the suppliers F and F 2 . Any piece of software can therefore choose to receive information from several suppliers by choosing the communication channel to which he must connect as a customer.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer And Data Communications (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Procédé de transmission asynchrone d'informations entre un fournisseur et un consommateur, conformément aux propriétés ACID, le fournisseur et le consommateur étant reliés par une chaîne de canaux de communication. Ce procédé se caractérise en ce que les informations sont transmises au moyen de transactions indépendantes établies: entre le fournisseur et le premier canal de communication de la chaîne, entre chacun des canaux de communication de la chaîne, et, entre le dernier canal de communication de la chaîne et le consommateur.

Description

Procédé de transmission asynchrone d'informations, possédant les propriétés ACID.
L'invention concerne le domaine de la transmission d'informations entre des fournisseurs et des consommateurs au travers une chaîne de canaux de communication. Plus particulièrement, l'invention consiste à effectuer cette transmission de façon asynchrone tout en respectant les propriétés dites ACID.
Les systèmes de communication utilisant des modes de transfert asynchrones sont de plus en plus utilisés. Les communications fiables sont nécessaires dans un grand nombre de cas. La fiabilité peut être assurée par l'ajout de mécanismes transactionnels au service de communication.
Un service de communication asynchrone comprend un gestionnaire et un ou plusieurs canaux de communication.
Un fournisseur (client du service) émet les informations en adressant un canal spécifique. Le canal transfère l'information au consommateur
(client du service aussi) en invoquant son interface. Le canal agit comme un intermédiaire entre deux clients en découplant la transmission de l'information d'un côté et de l'autre. Il faut pouvoir délivrer les informations de manière fiable tout en maintenant la désynchronisation entre les fournisseurs et les consommateurs.
Une solution connue pour transmettre les données de manière fiable s'appuie sur les systèmes de transactions. Une transaction est initiée par le fournisseur de données, puis est "propagée" aux éléments intermédiaires (canaux de communication) pour atteindre finalement le consommateur. Une fois les données délivrées, et avant de confirmer les modifications apportées (la livraison des données), les propriétés liées à l'exécution de la transaction sont vérifiées.
Il faut permettre la propagation de l'exécution de transactions à travers un canal de communication. Les canaux de communication asynchrones impliquent une désynchronisation entre les fournisseurs et les consommateurs alors que les transactions nécessitent une synchronisation pour permettre de suivre de bout en bout de l'exécution les propriétés de stabilité des transactions.
Une transaction doit satisfaire quatre propriétés regroupées sous l'acronyme ACID signifiant : Atomicité, Cohérence, Isolation et Durabilité. Ces quatre propriétés sont étroitement liées entre elles. Les mécanismes de contrôle de concurrence et de reprise mis en oeuvre par un moteur transactionnel ont pour objectif de les faire respecter.
L'atomicité garantit que, soit l'ensemble des mises à jour d'une transaction est effectué, soit aucune de ces mises à jour n'est effectuée. Le non-respect de cette propriété peut conduire à faire évoluer l'ensemble des données de l'état cohérent initial à un état incohérent.
Afin de faire respecter cette propriété, toute série d'action constituant une transaction est marquée par un début et une fin. Le début d'une transaction signale l'événement de début d'une transaction au moteur transactionnel. Deux ordres sont prévus pour marquer la fin d'une transaction :
"commit" permet à la transaction de signaler au moniteur transactionnel que du point isolé de la transaction toutes ses actions se sont bien passé. "Abort" permet à la transaction de signaler au moniteur transactionnel qu'une ou plusieurs de ses actions ont échoué et que la transaction ne souhaite pas être validée (les données modifiées par la transaction doivent êtres remis dans leur état précédent). En fonction de l'événement reçu en fin de transaction par le moniteur transactionnel et en fonction de la vue globale du système qu'il peut avoir (interaction entre transactions) le moniteur transactionnel décide ou non de valider la transaction c'est-à-dire de rendre définitives les modifications apportées par celle-ci Dans le cas où une panne système se produit avant la fin d'une transaction, celle-ci est considérée comme abandonnée. Un des mécanismes possibles afin de respecter la propriété d'atomicité consiste à conserver pour chaque transaction en cours l'image précédente de toute donnée mise à jour. En cas d'abandon d'une transaction, il est possible de défaire la transaction en appliquant toutes les images précédentes de la transaction.
La propriété de cohérence concerne la cohérence sémantique d'un ensemble de données. Le maintien de celle-ci peut être en partie assuré par les mécanismes assurant le contrôle de contraintes d'intégrité et par le maintien de la propriété des transactions.
L'isolation est indispensable en environnement multi-tâches, pour garantir que chaque transaction voit un état cohérent de l'ensemble des données. L'isolation consiste à garantir que si la transaction s'exécute en parallèle avec d'autres transactions (accédant a un ensemble commun de données), il existe une exécution en série des mêmes transactions qui produirait les mêmes changements à l'ensemble des données accédées par les transactions. Dans ce cas, la propriété d'isolation est vérifiée pour cet ensemble de transactions.
La durabilité garantit que les mises à jour d'une transaction validée sont définitives. La seule action qui doit permettre de défaire les mises à jour d'une transaction validée est l 'exécution d'une transaction de compensation. Cette propriété va de pair avec la propriété d'atomicité stipulant que les mises à jour d'une transaction forment un tout cohérent qui est soit abandonné dans son ensemble, soit validé durablement. Une méthode de réalisation en cas de panne mémoire ou de panne disque entraînant la perte d'une partie des informations de la base de donnée, consiste à disposer d'un mécanisme de reprise pour récupérer les informations perdues.
Il est nécessaire de posséder des mécanismes de communication asynchrones fiables de bout en bout. Il est difficile de combiner l'aspect asynchrone du transfert avec les transactions qui sont par essence synchrones.
Dans un système synchrone, une transaction peut être initiée et garantir depuis le fournisseur d'information jusqu'au consommateur le respect des propriétés ACID. Dans un système asynchrone, les actions garantissant ces propriétés doivent interαgir entre elles d'une manière fiable et déterminée, suivant la qualité de service désirée.
Le but de l'invention est donc de fournir un système de communication asynchrone ayant des propriétés ACID.
Pour cela, l'invention a pour objet un procédé de transmission asynchrone d'informations entre un fournisseur et un consommateur, conformément aux propriétés ACID, le fournisseur et le consommateur étant reliés par une chaîne de canaux de communication. Ce procédé se caractérise en ce que les informations sont transmises au moyen de transactions indépendantes établies :
• entre le fournisseur et le premier canal de communication de la chaîne,
• entre chacun des canaux de communication de la chaîne, et,
• entre le dernier canal de communication de la chaîne et le consommateur.
L'invention a pour autre objet un canal de communication, permettant la transmission asynchrone d'informations entre un fournisseur et un consommateur, conformément aux propriétés ACID. Ce canal possède un ensemble de clients, pouvant être d'autres canaux de communication et/ou des consommateurs et il se caractérise en ce qu'il comporte :
• des moyens pour mémoriser les informations contenues dans une transaction dont le canal est la cible,
• des moyens permettant de finaliser la transaction,
• des moyens pour initier des transactions contenant les informations, avec les clients, si la transaction a réussi.
Ainsi, le fait d'initier des transactions indépendantes pour chaque maillon de la chaîne permet de ne défaire que le minimum de transactions en cas de problème. Cela permet, bien évidemment, d'atteindre de bonnes performances en ce qui concerne le temps de délivrance des informations au consommateur.
Par ailleurs, le fournisseur n'initie une transaction qu'avec le premier canal de communication de la chaîne. Aussi, il obtiendra très rapidement le résultat ("commit" ou "Abort") de cette transaction, et ne demeura pas bloqué en attendant la délivrance des informations au consommateur. Autrement dit, l'objectif d'asynchronisme de la transmission est atteint.
Grâce au fait que toutes les transmissions intermédiaires sont effectuées au moyen de transactions, on a l'assurance de la délivrance des informations au consommateur avec le respect des propriétés ACID. Autrement dit, on peut dire qu'il y a une "transaction virtuelle" entre le fournisseur et le consommateur.
L'invention sera mieux comprise avec la description détaillée suivante d'une mise en oeuvre.
La figure 1 montre le principe général d'une chaîne de transactions selon l'invention.
La figure 2 montre un exemple de réseau de communication mettant en oeuvre des canaux de communication conforme à l'invention.
Dans la figure 1 , les fournisseurs, le canal de communication asynchrone et les consommateurs sont des objets virtuellement connectés en une chaîne unidirectionnelle de propagation des informations. Comme il sera plus précisément explicité plus loin, cette chaîne peut comporter plusieurs canaux de communication en cascade entre le fournisseur et les consommateurs.
Une transaction est initiée par un fournisseur, référencé 1 , à destination d'un canal de communication 2. Cette transaction comporte au moins les informations que le fournisseur désire transmettre aux consommateurs 5. Le canal de communication mémorise alors ces informations dans une mémoire fiable 4. Classiquement, cette mémoire fiable peut être une base de données possédant une interface XA et les mécanismes de reprises nécessaires. Ensuite, la transaction qui a été initiée par le fournisseur 1 , est finalisée. En cas de réussite de cette finalisation (ce qui correspond classiquement à l'émission d'un message "commit" vers le fournisseur), les informations contenues dans la transaction sont mémorisées dans des files d'attentes 6. Il y a une file d'attente par clients du canal. Un client du canal peut être un consommateur comme c'est le cas dans cet exemple, ou bien un autre canal de communication. Dans l'exemple de la figure 1 , on a donc deux files d'attente, chacune étant associée à un des deux consommateurs 5.
Selon une autre mise en œuvre possible, les informations sont stockées dans les files d'attente avant de finaliser la transaction, mais elles ne sont rendues disponibles (par exemple au moyen d'un identificateur de disponibilité associé à chaque file d'attente) que lorsque cette finalisation a réussi.
Il est à noter que plusieurs fournisseurs peuvent invoquer le même canal de communication 2 en parallèle. Ceci est rendu techniquement possible par l'utilisation de plusieurs fils d'exécution (aussi appelés processus légué, ou encore thread, selon la terminologie en langue anglaise).
De la même façon, un fil d'exécution existe pour chaque consommateur virtuellement connecté au canal. Le rôle de ces fils d'exécution est de consommer les informations stockées dans les files d'attente 6 afin d'initier des transactions avec les clients du canal de communication. Ces clients peuvent être des consommateurs 5, ou bien éventuellement d'autres canaux de communication. Ces transactions contiennent les informations stockées dans les files d'attente, et qui ont été précédemment reçues du fournisseur 1 . Les informations sont ainsi transmises le long de la chaîne.
Les clients (ici les consommateurs 5) finalisent alors les transactions. Si les transactions réussissent, le canal de communication reçoit en retour un message l'en avertissant ("commit"). Dans ce cas, les informations mémorisées dans la file d'attente 6 correspondant au client ayant transmis le
"commit", sont retirées.
Dans ce cas, on peut remarquer que le stockage fiable n'est jamais utilisé en lecture. Dans la mesure où le mémoire fiable est typiquement une base de données, on comprend que tout accès est pénalisant en terme de rapidité d'exécution. Ce procédé permet donc de minimiser les accès à la mémoire fiable, par l'utilisation de files d'attente bien plus rapides, et par conséquent d'accélérer la vitesse de transmission des informations du fournisseur vers les consommateurs.
Selon une mise en oeuvre de l'invention, chaque élément logiciel (fournisseur, canal de communication, consommateurs) fournit une interface standard de recouvrement pour reprise sur panne. Cette interface permet de défaire les actions faites par une transaction ayant échoué. De même la mémoire fiable fourni une interface permettant principalement de retirer du stockage des informations liées à une transaction. Ainsi, si une des transactions dans la chaîne échoue, l'ensemble des actions entreprises sur les objets impliqués par la transaction en question, est défait Une fois les actions défaites en raison de l'échec d'une transaction, la transaction peut être recommencée en lisant les informations stockées dans la mémoire fiable.
Comme cela a été annoncé plus haut, on remarque qu'en cas d'échec d'une transaction, celle-ci peut être défaite et recommencée sans remettre en question les autres transactions qui ont été effectuées précédemment dans la chaîne.
En cas de perte de l'état d'un canal, c'est-à-dire du contenu des files d'attente et de la connaissance de ses interconnections virtuelles, les mémoires fiables permettent de restaurer cet état.
Cette solution fournit un mécanisme de récupération de données de bout en bout, travaillant de manière automatique avec un système transactionnel externe. Comparé à d'autres solutions, ce mécanisme est générique.
Dans tous ce qui précède un seul canal de communication est considéré mais ce mécanisme étant symétrique il fonctionne de la même manière dans toute chaîne de canaux. Autrement dit, le nombre de canaux de communication entre le fournisseur et le ou les consommateurs peut être quelconque. Comme on l'a vue précédemment, dans une telle situation, un canal de communication peut se connecter en tant que client d'un autre canal de communication.
La figure 2 illustre un exemple de réseau de canaux de communication. Un fournisseur F, est connecté à un premier canal de communication. Un fournisseur F2 est connecté à un second canal de communication. Ces deux canaux de communication ont pour client un troisième canal de communication. Un ou plusieurs consommateurs C, sont connectés comme clients du premier canal de communication, tandis qu'un ou plusieurs consommateurs C2 sont connectés comme clients du deuxième canal de communication.
Une telle topologie de réseau possède un fort intérêt pratique. Il permet à des consommateurs C, de ne recevoir que les informations issues du fournisseur Fl 7 tandis que les consommateurs C2 reçoivent les informations des fournisseurs F et F2. Un élément logiciel quelconque peut donc choisir de recevoir les informations provenant de plusieurs fournisseurs en choisissant le canal de communication auquel il doit se connecter en tant que client.

Claims

Revendications
1 ) Procédé de transmission asynchrone d'informations entre un fournisseur et un consommateur, conformément aux propriétés ACID, ledit fournisseur et ledit consommateur étant reliés par une chaîne de canaux de communication, caractérisé en ce que lesdites informations sont transmises au moyen de transactions indépendantes établies :
• entre ledit fournisseur et le premier canal de communication de ladite chaîne,
• entre chacun des canaux de communication de ladite chaîne, et,
• entre le dernier canal de communication de ladite chaîne et ledit consommateur.
2) Procédé selon la revendication 1 , caractérisé en ce que chaque canal de communication possède un ensemble de clients, lesdits clients pouvant être d'autres canaux de communication et/ou des consommateurs, et en ce que lorsqu'un canal de communication de ladite chaîne est la cible d'une desdites transactions indépendantes, il met en oeuvre les étapes suivantes : • mémoriser lesdites informations dans une mémoire fiable,
• finaliser ladite transaction indépendante,
• si ladite transaction indépendante a réussi, initier des transactions indépendantes avec lesdits clients contenant lesdites informations.
3) Procédé selon la revendication précédente, caractérisé en ce que pour initier lesdites transactions indépendantes, lesdites informations sont mémorisées dans des files d'attente, chaque file d'attente étant associée à un desdits clients et consommée par un fil d'exécution. 4) Canal de communication, permettant la transmission asynchrone d'informations entre un fournisseur et un consommateur, conformément aux propriétés ACID, ledit canal possédant un ensemble de clients, lesdits clients pouvant être d'autres canaux de communication et/ou des consommateurs, caractérisé en ce qu'il comporte :
• des moyens pour mémoriser les informations contenues dans une transaction dont ledit canal est la cible,
• des moyens permettant de finaliser ladite transaction,
• des moyens pour initier des transactions contenant lesdites informations, avec lesdits clients, si ladite transaction a réussi.
5) Canal de communication selon la revendication précédente, caractérisé en ce qu'il comporte en outre des files d'attente, chaque file d'attente étant associée à un desdits clients.
6) Architecture de communication asynchrone transactionnelle utilisant une pluralité de canaux de communication selon l'une quelconque des revendications 4 ou 5.
EP00958660A 1999-08-16 2000-08-10 Procede de transmission asynchrone d'informations, possedant les proprietes acid Withdrawn EP1145121A3 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR9910516 1999-08-16
FR9910516 1999-08-16
PCT/FR2000/002292 WO2001013225A2 (fr) 1999-08-16 2000-08-10 Procede de transmission asynchrone d'informations, possedant les proprietes acid

Publications (2)

Publication Number Publication Date
EP1145121A2 true EP1145121A2 (fr) 2001-10-17
EP1145121A3 EP1145121A3 (fr) 2002-09-11

Family

ID=9549160

Family Applications (1)

Application Number Title Priority Date Filing Date
EP00958660A Withdrawn EP1145121A3 (fr) 1999-08-16 2000-08-10 Procede de transmission asynchrone d'informations, possedant les proprietes acid

Country Status (4)

Country Link
EP (1) EP1145121A3 (fr)
JP (1) JP2003507789A (fr)
AU (1) AU7010900A (fr)
WO (1) WO2001013225A2 (fr)

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2301686A (en) * 1995-06-03 1996-12-11 Ibm Transaction synchronisation procedure in a routing node
EP0817019B1 (fr) * 1996-07-02 2003-01-29 International Business Machines Corporation Méthode de traitement stratifié de transactions

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO0113225A3 *

Also Published As

Publication number Publication date
AU7010900A (en) 2001-03-13
EP1145121A3 (fr) 2002-09-11
WO2001013225A2 (fr) 2001-02-22
WO2001013225A3 (fr) 2001-08-30
JP2003507789A (ja) 2003-02-25

Similar Documents

Publication Publication Date Title
US9632828B1 (en) Computing and tracking client staleness using transaction responses
EP0005722B1 (fr) Système de sélection de circuit d'interface prioritaire
FR2756070A1 (fr) Systeme de gestion et de traitement de transactions distribuees d'objets et procede mis en oeuvre par ledit systeme
CN102546776B (zh) 一种san共享文件系统中实现离线读文件的方法
FR2476349A1 (fr) Systeme de traitement de donnees reparti
EP0665494A1 (fr) Circuit décodeur insensible à la fluctuation de tension d'alimentation
US9264519B1 (en) Embedding application services in a distributed datastore
FR2865334A1 (fr) Procede et systeme de transmission de messages dans un reseau d'interconnexions.
EP0969625B1 (fr) Agent de communication entre un administrateur et au moins une ressource d'un système informatique
EP1376437A1 (fr) Procédé de prédiction d'évènements de trafic aérien, notamment pour une aide à la décision des compagnies aériennes et des aéroports
FR2860616A1 (fr) Unite de commande de dispositif de memorisation et procede de commande de celui-ci
CA2089864A1 (fr) Systeme de relais de transport osi entre un reseau en mode connecte et un reseau en mode non connecte
WO2001013225A2 (fr) Procede de transmission asynchrone d'informations, possedant les proprietes acid
FR2819321A1 (fr) Procede de traitement et d'acces a des donnees dans un systeme de reservation par ordinateur, et systeme de mise en oeuvre
EP2442518A1 (fr) Procédé de traitement de requêtes SIP initiales par des backends d'un groupe SIP en présence d'une défaillance, et dispositif de traitement associé
FR2944366A1 (fr) Procede et dispositif permettant l'execution de composants transactionnels heterogenes
BE1003811A3 (fr) Systeme de test integre pour test de conformite de systemes de communication.
EP2278466A1 (fr) Dispositif et procédé pour l'exécution distribuée de traitements de données numériques
EP1871058B1 (fr) Système et procédé de gestion de messages transmis dans un réseau d'interconnexions.
FR2836611A1 (fr) Procede de communication reseau avec une carte a puce par messages asynchrones
FR2766937A1 (fr) Protocole et systeme de liaison par bus entre elements d'un microcontroleur
WO2005055060A1 (fr) Dispositif et procede asynchrones et automatiques de transmission de resultats entre objets communicants
CA2137620C (fr) Procede de simulation d'une architecture "serveur" a partir d'une architecture "client"
EP0524076B1 (fr) Système logiciel composite et son procédé de réalisation
FR3067490A1 (fr) TRAITEMENT DE MESSAGES MULTlNORMES

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE

AX Request for extension of the european patent

Free format text: AL;LT;LV;MK;RO;SI

XX Miscellaneous (additional remarks)

Free format text: DERZEIT SIND DIE WIPO-PUBLIKATIONSDATEN A3 NICHT VERFUEGBAR.

PUAK Availability of information related to the publication of the international search report

Free format text: ORIGINAL CODE: 0009015

17P Request for examination filed

Effective date: 20020228

AK Designated contracting states

Kind code of ref document: A3

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE

AX Request for extension of the european patent

Free format text: AL;LT;LV;MK;RO;SI

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ALCATEL LUCENT

17Q First examination report despatched

Effective date: 20070830

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20080311