Paramètres du service de transaction

Indique le nom d'un répertoire pour le serveur où le service Transactions stocke les fichiers de journalisation pour la reprise. En option, vous pouvez indiquer la taille des fichiers de journaux de transaction. Pour la plateforme z/OS, définit l'emplacement du journal de partenaire JTA.

Définissez cette propriété pour changer le répertoire du fichier journal des transactions d'un serveur d'applications uniquement si les applications utilisent des ressources distribuées ou des transactions XA, par exemple lorsqu'une même transaction accède à plusieurs bases de données et ressources.

Si vous n'indiquez pas ce répertoire pendant la configuration du serveur, le service de transaction utilise un répertoire par défaut fondé sur le répertoire d'installation : racine_serveur_app/ tranlog/nom_cellule/nom_noeud/nom_serveur.

Lorsqu'une application exécutée sur WebSphere Application Server a accès à plusieurs ressources, le serveur d'applications stocke les informations sur la transaction dans le répertoire du produit afin de coordonner et de gérer correctement la transaction distribuée. Quand la charge de transaction est plus élevée, le stockage des informations persistantes peut ralentir considérablement les performances du serveur d'applications, car ce dernier est tributaire du système d'exploitation et des systèmes de stockage sous-jacents. Pour de meilleures performances, indiquez un nouveau répertoire pour les fichiers journaux sur un système de stockage distinct, physiquement plus grand.

Si votre serveur d'applications présente un ou plusieurs des symptômes suivants, changez le répertoire du journal des transactions :

• L'utilisation de l'unité centrale reste faible malgré l'augmentation du nombre de transactions
• Les transactions échouent après plusieurs dépassements du délai d'expiration.
• Des transactions sont annulées en raison de l'exception "échec de l'inscription de la transaction".
• Le serveur d'applications se bloque en plein milieu d'une exécution et doit être redémarré
• Le disque sur lequel le serveur d'applications s'exécute présente une plus grande activité

Voici les recommandations qui s'appliquent pour le système de stockage des fichiers journaux :

• Stockez les fichiers journaux sur un réseau redondant de disques indépendants (RAID).

  Dans les configurations RAID, la tâche qui consiste à enregistrer des données sur un support physique est partagée entre plusieurs unités. Cette technique permet un nombre plus élevé d'accès simultanés pour la conservation des informations relatives aux transactions et un accès plus rapide à ces données dans les journaux. Selon la conception de l'application et du sous-système de stockage, une optimisation de 10 à 100 % des performances peut être obtenue dans plusieurs cas.

• Ne stockez pas les fichiers journaux avec le mode d'E-S du système d'exploitation associé à la valeur CIO (E-S simultanée).

  Lorsque vous définissez un répertoire pour le journal des transactions, vérifiez que le système de fichiers utilise uniquement des opérations d'écriture immédiate et de sérialisation d'écriture synchrones. Certains systèmes d'exploitation tels qu'AIX JFS2 prennent en charge un mode CIO (E-S simultanée) facultatif où le système de fichiers n'applique pas la sérialisation des opérations d'écriture. N'utilisez pas le mode CIO pour les fichiers journaux de reprise de transaction du serveur d'applications sur ces systèmes.

Pour indiquer la taille des fichiers journaux de transaction, précisez la taille des fichiers. Utilisez l'un des formats suivants, où nom_répertoire est le nom du répertoire de journal de transaction et taille_fichier est la nouvelle allocation d'espace du disque pour les fichiers journaux de transactions mesurée en Ko (nK) ou Mo (nM). La taille minimale de fichier journal des transactions que vous pouvez spécifier est 64 ko. Si vous spécifiez une valeur inférieure à 64 ko ou si vous ne spécifiez pas de valeur, la valeur par défaut de 1 Mo est utilisée.

;file_size   <!-- Ce format maintient le répertoire par défaut -->

nom_répertoire;taille_fichier

dir://directory_name/directory_name;file_size

/directory_name/directory_name;file_size

Pour plus d'informations sur les tailles de journaux de transactions, voir Gestion de la journalisation des transactions pour une disponibilité optimale du serveur.

Informations	Value
Type de données	String (chaîne)
Valeur par défaut	Nom du répertoire : racine_serveur_app/tranlog/nom_cellule/nom_noeud/nom_serveur Taille du fichier : 1 Mo
Recommandé	Créez un système de fichiers comportant au moins trois ou quatre unités de disque reliées entre elles par une configuration RAID-0. Créez ensuite le journal des transactions sur ce système de fichiers en lui affectant la taille par défaut. Lorsque le serveur traite une charge de travail, vérifiez les entrées et sorties des disques. Si la durée des entrées et sorties des disques est supérieure à 5 %, il est conseillé d'ajouter davantage de disques pour réduire ce pourcentage.

Sous z/OS, ce journal est utilisé pour la récupération des ressources XA. Lorsque l'application exécutée dans WebSphere accède à des ressources XA, WebSphere stocke les informations sur la ressource pour permettre la récupération de la transaction XA. Utilisez la syntaxe suivante :

[balise URL de type d'emplacement] spécification_emplacement

• balise d'URL de type d'emplacement indique le type d'emplacement facultatif du journal JTA Partner :
  • La valeur par défaut est dir://, qui indique que l'emplacement du journal JTA Partner se trouve dans un répertoire de système hiérarchique de fichiers qualifié complet spécifié par spécification_emplacement.
• spécification de l'emplacement indique l'emplacement du journal JTA Partner :
  • Pour spécifier un flot de journalisation, utilisez la syntaxe logstream://HLQ
    Si l'installation du serveur d'applications a suivi la convention de configuration des flots de journalisation dans l'unité de couplage (CF), le flot de journalisation est nommé en fonction de la syntaxe HLQ.server.X, où HLQ est une valeur de 1 à 8 caractères définie par l'utilisateur dans la boîte de dialogue d'installation. Utilisez cette valeur HLQ pour indiquer l'emplacement du journal JTA Partner.

    Eviter les incidents : Définissez AUTODELETE(NO) pour tout flot de journalisation.gotcha
  • Si la balise d'URL de type d'emplacement est dir://, utilisez un répertoire HFS complet pour la spécification d'emplacement. Le nom complet du répertoire doit être unique dans le noeud WebSphere.

La valeur par défaut est dir://racine_serveur_app/tranlog/nom_serveur.

Pour indiquer la taille des fichiers journaux de transaction, précisez la taille des fichiers. Utilisez l'un des formats suivants, où nom_répertoire est le nom du répertoire de journal de transaction et taille_fichier est la nouvelle allocation d'espace du disque pour les fichiers journaux de transactions mesurée en Ko (nK) ou Mo (nM). La taille minimale de fichier journal des transactions que vous pouvez spécifier est 64 ko. Si vous spécifiez une valeur inférieure à 64 ko ou si vous ne spécifiez pas de valeur, la valeur par défaut de 1 Mo est utilisée.

dir://directory_name/directory_name;file_sizeK

/directory_name/directory_name;file_sizeK

;file_sizeK   <!-- Ce format maintient le répertoire par défaut -->

Temps maximal par défaut, en secondes, dont dispose une transaction démarrée sur ce serveur pour se terminer. Toutes les transactions qui ne lancent le processus d'arrêt avant ce délai d'attente sont annulées.

Ce délai d'expiration des transactions est utilisé uniquement si le composant d'application ne définit pas lui-même le sien.

Après l'expiration du délai, les transactions sont autorisées à poursuivre leur exécution durant une période de grâce d'environ quatre minutes. Si la transaction est validée ou annulée pendant cette période de grâce, la sortie de la transaction est toujours annulée. Si la transaction n'est pas terminée après la période de grâce, le contrôleur arrête anormalement la région serviteur dans laquelle le composant d'application s'exécute, avec ABEND EC3 RSN=04130002 ou 04130005.

Remarque : Seul le délai de la durée de vie totale de la transaction et le délai d'expiration maximal de la transaction possèdent des périodes de grâce. Vous pouvez désactiver les périodes de grâce à l'aide de la propriété personnalisée DISABLE_TRANSACTION_TIMEOUT_GRACE_PERIOD.

La limite supérieure de ce délai d'expiration dépend du délai d'expiration maximal des transactions. Si, par exemple, vous attribuez la valeur 500 au paramètre de dépassement du délai autorisé pour la durée de vie des transactions et la valeur 300 au délai d'expiration maximal des transactions, les transactions expireront après 300 secondes.

Si vous définissez le paramètre de dépassement du délai sur 0, il ne s'applique pas et la valeur du délai maximal est utilisée en son lieu et place.

Informations	Value
Type de données	Entier
Unité	Valeur par défaut
Valeur par défaut	120
Plage de valeurs	0 à 2 147 483 647
Plage de valeurs	0 à 2 147 040

Indique le temps d'attente en secondes dont dispose le serveur pour répondre au protocole WS-AT entrant avant de renvoyer le message du protocole WS-AT précédent.

Indique la durée maximale, en secondes, entre deux demandes transactionnelles d'un client distant. Toute période d'inactivité du client qui dépasse cette expiration entraîne l'annulation de cette transaction sur ce serveur d'applications.

Si vous définissez cette valeur sur 0, aucune limite de dépassement du délai n'est appliquée.

Indique la limite supérieure du délai de transaction en secondes pour les transactions exécutées sur ce serveur. Cette valeur doit être supérieure ou égale à la valeur spécifiée pour le délai total des transactions.Définit en secondes la durée maximale d'exécution des transactions sur ce serveur. Cette valeur doit être supérieure ou égale au délai total des transactions ET supérieure ou égale au délai du composant d'application. Si le délai d'expiration maximal des transactions est inférieur au délai total des transactions ou au délai du composant d'application, les transactions ayant besoin de plus de temps arriveront à expiration une fois le délai d'attente maximal des transactions atteint.

Cette valeur de délai d'attente contraint la limite supérieure de tous les autres délais d'attente de transaction.

Si vous définissez un délai d'expiration sur 0, le délai ne s'applique pas et est désactivé. Si vous définissez tous les délais d'expiration sur 0, les transactions n'expirent jamais.

Pour déterminer rapidement l'occurrence d'un délai et éviter d'autres verrouillages de ressources, le serveur d'applications bloque les autres travaux de transaction sur le chemin transactionnel où la condition d'expiration a eu lieu. Cela s'applique également aux tentatives de travaux sous le contexte transactionnel en cours et sous un contexte transactionnel différent.

Informations	Value
Type de données	Entier
Unité	Valeur par défaut
Valeur par défaut	300
Plage de valeurs	0 à 2 147 483 647
Plage de valeurs	0 à 2 147 040

Indique le nombre de fois que le serveur d'applications tente de renvoyer un signal d'achèvement, comme la validation ou l'annulation. Les nouvelles tentatives ont lieu après une exception transitoire d'un gestionnaire de ressources ou d'un partenaire distant, ou si le délai d'attente de réponse asynchrone configuré expire avant la réponse de tous les partenaires WS-AT (Web Services Atomic Transaction).

Si le serveur d'applications n'effectue pas de nouvelle tentative, le gestionnaire de ressources ou le partenaire éloigné est alors chargé de vérifier que la branche de la ressource ou du partenaire de la transaction a été exécutée de manière appropriée. Le serveur d'applications lance une exception (au nom de la ressource ou du partenaire) qui indique un risque heuristique. Si une validation a été demandée, l'émetteur de la transaction reçoit une exception dans l'opération de validation ; si la transaction est lancée par le conteneur, ce dernier renvoie une exception distante ou une exception Enterprise JavaBeans (EJB) au client d'EJB.

Lors de la récupération d'un serveur subordonné dans une transaction distribuée, si le nombre de nouvelles tentatives heuristiques est dépassé, la propriété de direction de l'achèvement heuristique indique comment la transaction est effectuée.

Indique le nombre de secondes que le serveur d'applications attend avant de tenter à nouveau un signal d'exécution (une validation ou une annulation, par exemple) après une exception temporaire émise par un gestionnaire de ressources ou un partenaire distant.

Indique si le serveur d'applications consigne les événements liés aux ressources à validation en une phase associées à des transactions faisant appel à une ressource de validation à une et deux phases.

Cette propriété active la journalisation d'états heuristiques. Si la configuration de certaines applications autorise des ressources de validation à une phase à participer à des transactions de validation à deux phases, la consignation d'événements heuristiques dans le journal des transactions en cas de panne du serveur peut nécessiter des informations supplémentaires. Dans ce cas, un autre enregistrement est effectué dans le journal pour toute transaction impliquant des ressources de validation à une phase et à deux phases. Aucun autre enregistrement n'est inscrit pour les transactions n'impliquant pas de ressource de validation à une phase.

Indique la direction suivie pour terminer une transaction avec un résultat heuristique : le serveur d'applications valide ou annule la transaction, ou bien dépend d'une exécution manuelle par l'administrateur.

Cette propriété ne s'applique qu'aux transactions qui se trouvent dans les situations décrites précédemment.

Indique si toutes les applications sur ce serveur acceptent la possibilité qu'un danger heuristique survienne dans une transaction à deux phases contenant une ressource à phase unique. Cette valeur configure la prise en charge du participant (LPS) pour le serveur. Le support du dernier participant est une extension du service de transaction permettant à une ressource à phase unique de participer à une transaction à deux phases avec une ou plusieurs ressources à deux phases.

Si l'option Accepter les risques heuristiques n'est pas sélectionnée, vous devez configurer individuellement les applications pour accepter le risque heuristique. Vous pouvez configurer les applications soit lors de leur assemblage soit après le déploiement à l'aide du panneau Extension au support du dernier participant.

Indique si l'utilisation de verrous de fichiers est activée lors de l'ouverture du journal de reprise du service Transactions.

Indique si l'échange sécurisé de messages de protocole du service Transactions est activé.

Lorsque l'autorisation de coordination des transactions est activée, le service de transaction vérifie que l'appelant est autorisé à accéder au rôle administrateur avant de gérer la transaction.

Ce paramètre est sans effet si la sécurité de WebSphere Application Server est désactivée sur le serveur.

Indique le niveau de spécification par défaut de WS-Transaction à utiliser pour les demandes sortantes qui incluent un contexte de coordination WS-AT (Web Services Atomic Transaction) ou WS-BA (Web Services Business Activity).

Vous avez le choix entre WS-Transaction 1.0, WS-Transaction 1.1 et WS-Transaction 1.2. Pour plus de détails sur ces spécifications, reportez-vous aux rubriques sur le support WS-AT ou WS-BA sur le serveur d'applications.

Le niveau de spécification WS-Transaction par défaut est utilisé si aucun niveau ne peut être déterminé à partir de la règle du fournisseur (assertion WS-Transaction WS-Policy). Cela peut se produire, par exemple, si l'assertion de règle n'est pas disponible à partir du WSDL du service Web cible ou du type de règle WS-Transaction du client ou que l'assertion de règle est disponible, mais que plusieurs niveaux de spécification sont applicables.

Sélectionnez ou spécifiez le préfixe de l'URL HTTP(S) WS-Transaction externe.

• Si vous utilisez un noeud intermédiaire tel qu'un serveur HTTP ou un serveur proxy pour WebSphere afin d'envoyer des demandes conformes aux protocoles de transaction atomique de services Web (Web Services Atomic Transaction) ou d'activité métier de services Web (Web Services Business Activity).
• Si vous voulez configurer WS-Transaction EndpointReferences en vue de sa publication avec des valeurs de protocole, d'hôte et de port autres que des valeurs par défaut dans les adresses URL. Par exemple, lorsque vous configurez des demandes de protocole WS-Transaction entrantes pour qu'elles soient transmises au serveur d'applications via un proxy direct tel qu'un serveur proxy WebSphere, utilisez cette zone pour spécifier une chaîne de canaux SSL lorsque la sécurité globale est désactivée, ou pour spécifier un canal non SSL lorsque la sécurité globale est activée.

Si un préfixe personnalisé spécifié ou un préfixe sélectionné est configuré, ce préfixe est utilisé. Si aucun préfixe sélectionné ou personnalisé spécifié n'est défini, alors, par défaut, si la sécurité est activée, l'une des chaînes de canaux de conteneur Web compatible avec SSL du serveur d'applications est sélectionnée automatiquement. Sinon, une chaîne de canaux de conteneur Web compatible avec des protocoles non SSL est sélectionnée automatiquement.

Eviter les incidents : La définition de l'autorisation de coordination des transactions n'a pas d'effet sur la sélection SSL/non SSL. Pour plus d'informations sur la relation entre l'autorisation de coordination des transactions et les paramètres WS-Transaction, voir la rubrique Configuration de la prise en charge de la transaction des services Web dans un environnement sécurisé. gotcha

Si le noeud intermédiaire n'est pas un serveur proxy, le préfixe doit être unique pour chaque serveur.

Si vous utilisez un serveur proxy, les préfixes peuvent être identiques pour tous les serveurs d'un cluster, car le serveur proxy détermine de façon dynamique le serveur auquel transmettre la demande.

Sélectionnez cette option pour sélectionner les informations sur l'URL du noeud final externe à utiliser pour les noeuds finaux de service WS-AT et WS-BA dans la liste.

Sélectionnez cette option pour définir les informations sur l'URL du noeud final externe à utiliser pour les noeuds finaux de services WS-AT et WS-BA dans cette zone.

http://nom_hôte:port

https://nom_hôte:port

Indique le nombre de transactions devant être achevées manuellement par un administrateur.

Si des transactions doivent être achevées manuellement, vous pouvez cliquer sur le lien Consulter pour en afficher la liste dans le panneau Transactions pour lesquelles une action manuelle est requise.

Indique le nombre de transactions comportant des ressources faisant l'objet de nouvelles tentatives.

Si des transactions comportent des ressources faisant l'objet de nouvelles tentatives, vous pouvez cliquer sur le lien Consulter pour en afficher la liste dans le panneau Transactions pour lesquelles une action manuelle est requise.

Indique le nombre de transactions ayant été achevées de manière heuristique.

Si des transactions ont été achevées de manière heuristique, vous pouvez cliquer sur le lien Consulter pour en afficher la liste dans le panneau Transactions avec sortie heuristique.

Indique le nombre de transactions importées et préparées, mais pas encore validées.

Si des transactions ont été importées et préparées mais non encore validées, vous pouvez cliquer sur le lien Consulter pour en afficher la liste dans le panneau Transactions importées et préparées.

Sous Propriétés supplémentaires, vous pouvez cliquer sur le lien Propriétés personnalisées pour afficher ou modifier les propriétés personnalisées de votre service de transaction WebSphere Application Server.

L'option Propriétés personnalisées permet de définir si les messages d'informations s'affichent ou non sur la console d'administration et s'ils sont intégrés au fichier SystemOut.log lors de la récupération du service de transaction.

Pour plus d'informations sur les propriétés personnalisées du service de transaction WebSphere Application Server, cliquez sur le lien correspondant.