Validation de la priorité pour les ressources transactionnelles
Vous pouvez indiquer l'ordre dans lequel les ressources transactionnelles sont traitées lors d'un processus de validation en deux phases.
- L'optimisation de la validation en une phase est plus fréquente.
- Les incidents potentiels entraînés par l'isolement de transactions sont résolus.
Pour décider l'ordre dans lequel les ressources transactionnelles sont traitées lors d'un processus de validation en deux phases, indiquez la priorité de validation d'une ressource en définissant l'attribut correspondant dans une référence à cette ressource. Plus la priorité est élevée, plus tôt le ressource est traitée. Par exemple, si la priorité de validation d'une ressource est de 10, elle est traitée avant une ressource de priorité 1. La valeur de la priorité de validation est de type int et peut être comprise entre -2147483648 et 2147483647.
Si vous n'indiquez pas de priorité de validation, une valeur par défaut de 0 est attribuée à la ressource et employée lors de l'organisation des ressources au moment de l'exécution. Si deux ressources ou plus sont configurées avec la même priorité, y compris la priorité par défaut, elles sont traitées dans un ordre quelconque.
Vous pouvez indiquer l'attribut de priorité de validation dans une référence à la ressource à l'aide des outils de Rational Application Developer. Pour des informations détaillées, voir le centre de documentation de Rational Application Developer. Le composant d'application doit posséder un descripteur de déploiement. Vous ne pouvez pas indiquer cet attribut si une annotation a été utilisée.
Optimisation de la validation en une phase
Dans une transaction avec une validation en deux phases, si toutes les ressources sauf la dernière figurant dans cette transaction donnent une réponse en lecture seule (le résultat de la transaction est donc sans incidence sur elles), une validation en une phase se produit. Dans ce cas, le service Transactions n'a pas besoin de stocker des informations sur les ressources et sur la transaction qui seraient nécessaires pour annuler une validation en deux phases : les performances sont donc améliorées.
Vous pouvez décider l'ordre dans lequel les ressources transactionnelles sont traitées lors de la validation en deux phases, afin de traiter celles susceptibles d'envoyer d'abord une réponse en lecture seule. Par conséquent, vous avez plus de chances qu'une validation en une phase se produise.
![[z/OS]](../images/ngzos.gif)
Isolement de transactions
Lorsque des ressources interviennent dans une transaction globale, les mises à jour effectuées dans le cadre d'une transaction ne sont pas visibles hors de cette transaction tant que celle-ci n'est pas validée, à savoir que les ressources sont isolées. Cet isolement peut provoquer des incidents avec d'autres composants d'application qui agissent sur les mises à jour après leur validation. Par exemple, les traitements ultérieurs peuvent échouer systématiquement ou ponctuellement, car les mises à jour dépendent de l'ordre et de l'heure. Cet incident n'a pas lieu avec la messagerie du bus d'intégration de services dans WebSphere Application Server, mais il peut se produire pour d'autres fournisseurs de messagerie comme WebSphere MQ.
Si vous précisez l'ordre dans lequel les ressources transactionnelles sont validées, les incidents provoqués par l'isolement sont résolus pour tous les systèmes transactionnels, et pas seulement pour des fournisseurs de messagerie et des bus d'intégration de services déterminés.
L'exemple suivant décrit comment des incidents peuvent se produire lorsque vous ne pouvez pas décider l'ordre dans lequel les ressources transactionnelles sont validées. Une application met à jour une ligne dans une table d'une base de données, puis envoie un message JMS déclenchant le traitement de cette ligne. Ces deux actions sont exécutées dans la même transaction globale et sont donc isolées tant que leurs ressources respectives ne sont pas validées. Si la mise à jour de la ligne est validée avant l'envoi du message, le processus déclenché par le message peut accéder à cette ligne et la traiter. Si l'envoi du message est validé en premier, il peut déclencher le traitement de la ligne avant la validation de la mise à jour de la ligne par la base de données. Dans ce cas, la ligne mise à jour reste isolée et n'est pas visible, ce qui fait échouer son traitement.
Cet incident peut être plus compliqué sachant qu'il dépend de l'ordre et de l'heure. Si la base de données est d'abord validée, l'incident n'a pas lieu. Si l'envoi du message est d'abord validé, l'incident peut se produire : tout dépend si le travail de la base de données est validé avant le déclenchement du traitement de la ligne par le message. L'incident est donc intermittent et il est difficile d'en identifier la cause.
Restrictions avec les versions antérieures de WebSphere Application Server
Si vous indiquez la priorité de validation d'une ressource en indiquant une valeur autre que 0, elle est ajoutée au journal du partenaire dans une section d'unité remédiable. Cette section du fichier journal est reconnue dans WebSphere Application Server Version 7.0 (ou version ultérieure) mais pas dans les versions antérieures du serveur d'applications.
Si une application utilise l'attribut de priorité de validation, vous ne pouvez pas l'installer dans un cluster contenant différentes versions si un ou plusieurs des serveurs du cluster utilisent des versions de WebSphere Application Server antérieures à la version 7.0.
De même, si une application utilise l'attribut de priorité de validation, vous ne pouvez pas ajouter dans ce cluster un serveur utilisant une version de WebSphere Application Server antérieure à la version 7.0.
Pour des informations générales sur les différentes versions du produit, voir "Présentation de la migration, de la coexistence et de l'interopérabilité".