Propriétés de la source de données WebSphere Application Server

Cette page permet de définir les propriétés avancées de la source de données du serveur d'applications. Ces propriétés activent et configurent des services que le serveur d'applications applique aux sources de données pour personnaliser les connexions dans un serveur d'applications. Ces propriétés n'ont aucune conséquence sur les connexions dans la base de données.

Pour accéder à cette page de la console d'administration, suivez un des chemins suivants :
  • Ressources > JDBC > Sources de données > source_données > Propriétés de la source de données WebSphere Application Server
  • Ressources > JDBC > Fournisseurs JDBC > fournisseur_JDBC > Sources de données > source_données > Propriétés de la source de données WebSphere Application Server
  • Applications > Types d'application > Applications d'entreprise WebSphere > nom_application > Ressources sectorisées d'application > source_données > Propriétés de source de données WebSphere Application Server.

Taille de la cache d'instructions

Indique le nombre d'instructions par connexion pouvant être placées en mémoire cache. Le serveur d'applications place une instruction dans la mémoire cache une fois que vous avez fermé cette instruction.

La source de données WebSphere Application Server optimise le traitement des instructions préparées et des instructions d'appel en plaçant dans la mémoire cache celles qui ne sont pas utilisées dans une connexion active. Les deux types d'instruction permettent d'optimiser les performances des transactions entre votre application et le magasin de données.
  • Une instruction préparée est une instruction SQL précompilée stockée dans un objet PreparedStatement. Le serveur d'applications utilise cet objet pour exécuter l'instruction SQL plusieurs fois, selon les conditions de la phase d'exécution de votre application, avec des valeurs déterminées par la phase d'exécution.
  • Une instruction d'appel est une instruction SQL contenant un appel vers une procédure mémorisée, qui correspond à une série d'instructions précompilées effectuant une tâche et renvoyant un résultat. Elle est stockée dans l'objet CallableStatement. Le serveur d'applications utilise cet objet pour exécuter une procédure mémorisée plusieurs fois, selon les conditions de la phase d'exécution de votre application, avec des valeurs déterminées par la phase d'exécution.

Si la taille de la mémoire cache d'instructions n'est pas suffisante, il se peut que certaines entrées utiles soient effacées pour laisser de la place aux nouvelles entrées. Pour déterminer une taille maximale pour votre cache et éviter ainsi d'effectuer des suppressions dans ce dernier, ajoutez le nombre d'instructions préparées uniques et appelables ,déterminé par la chaîne SQL, le mode d'accès concurrent et le type de défilement, pour chaque application qui utilise cette source de données sur un serveur spécifique. Cette valeur représente le nombre maximal d'instructions préparées qui peuvent être placées dans la mémoire cache sur une connexion donnée au cours de l'utilisation du serveur. Si vous l'attribuez à la taille du cache, aucune donnée n'est jamais supprimée du cache. Généralement, configurez une mémoire cache plus grande pour les applications possédant un nombre plus important d'instructions.

[AIX Solaris HP-UX Linux Windows][IBM i]Vous pouvez également utiliser Tivoli Performance Viewer pour réduire au minimum les suppressions du cache. Utilisez une charge de travail standard représentant un nombre typique de demandes client entrantes, un nombre fixe d'itérations et un jeu standard de paramètres de configuration.
Remarque : Plus la mémoire cache des instructions est importante, plus les ressources système sont retardées. C'est pourquoi, si vous choisissez un nombre trop élevé, vous risquez de manquer de ressources car votre système ne peut pas ouvrir plusieurs instructions préparées.

Si vous ne souhaitez pas que le serveur d'applications mette en mémoire cache une instruction particulière, affectez la valeur false à l'indice de regroupement de l'instruction. Le serveur d'applications ne met pas une instruction en mémoire cache si l'indice de regroupement a pour valeur false. L'application spécifie les indices de regroupement des instructions au moment de l'exécution.

Lors des tests, le paramétrage de la mémoire cache des instructions a permis d'augmenter le débit entre 10 et 20 %. Toutefois, la disponibilité limitée des ressources ne permet pas toujours cette optimisation.

Information valeur
Type de données Entierr
Valeut par défaut Les valeurs par défaut dépendent de la base de données. Généralement, cette valeur est égale à 10. Pour Informix versions 7.3, 9.2, 9.3 et 9.4, sans les derniers correctifs appropriés, la valeur par défaut doit être 0. Une valeur par défaut de 0 signifie qu'il n'existe aucune instruction de cache.

Activez la détection d'accès multiprocessus

Lorsqu'elle est activée, l'un des deux messages ci-après ou les deux sont entrés dans le journal des sorties système WebSphere Application Server si plusieurs unités d'exécution tentent d'utiliser le même descripteur de connexion. Vous pouvez utiliser cette propriété pour déboguer les problèmes de connexion si vous pensez qu'ils peuvent être liés à différentes tentatives d'utilisation du même descripteur de connexion par plusieurs unités d'exécution. L'utilisation simultanée du même descripteur de connexion par plusieurs unités d'exécution constitue une violation du modèle de programmation.
Remarque : En fonction des circonstances de traitement exactes, l'utilisation de connexions gérées peut générer le message J2CA0167W ou DSRA8720W (ou les deux). Vous devez les rechercher dans les journaux de travaux si Activer la détection des accès comprenant plusieurs unités d'exécution est activé.

J2CA0167W: Une tentative d'utilisation simultanée du même descripteur de connexion par plusieurs unités d'exécution a été détectée. Le descripteur de connexion est : {0}.

DSRA8720W: Accès impliquant plusieurs unités d'exécution détecté sur {0}. Dernière utilisation avec l'ID d'unité d'exécution : {1} ID accès multiprocessus. ID d'unité d'exécution actuelle : {2} Trace de pile de l'unité d'exécution : {3}

Activer la réauthentification de la base de données

Indique qu'il ne peut y avoir de correspondance exacte des connexions extraites du pool de connexions du serveur d'applications (les critères de recherche du pool de connexions n'incluent pas de nom d'utilisateur et de mot de passe). A la place, la réauthentification de connexion est effectuée dans la méthode doConnectionSetupPerTransaction() de la classe DataStoreHelper. Le serveur d'applications ne fournit pas d'implémentation de réauthentification de connexion lors de l'exécution. C'est pourquoi, lorsque vous sélectionnez cette case à cocher, vous devez étendre la classe DataStoreHelper pour fournir l'implémentation de la méthode doConnectionSetupPerTransaction() où la réauthentification a lieu. Lorsque vous ne suivez pas ce processus, le serveur d'applications peut renvoyer des connexions non utilisables. Pour plus d'informations, voir la documentation API relative à la méthode com.ibm.websphere.rsadapter.DataStoreHelper#doConnectionSetupPerTransaction.

La nouvelle authentification de connexion peut améliorer les performances car elle réduit les ouvertures et les fermetures de connexions, en particulier pour les applications qui requièrent souvent des connexions avec des noms d'utilisateur et des mots de passe différents.
Eviter les incidents Eviter les incidents: Vous ne pouvez pas activer la réauthentification de la base de données si vous sélectionnez TrustedConnectionMapping pour l'alias de configuration de mappage.gotcha

Activez la prise en charge JMS de l'optimisation en une phase.

Lorsque vous sélectionnez cette option, le serveur d'applications utilise JMS (Java™ Message Service) pour obtenir des connexions optimisées à partir de cette source de données. Cette propriété empêche les applications JDBC (Java database connectivity) de partager des connexions avec les applications CMP. Cette option n'est pas disponible si le fournisseur JDBC de la source de données est un fournisseur XA.

Gérer les descripteurs placés en cache

Indique si le conteneur fait le suivi des descripteurs placés en cache ; il s'agit de descripteurs de connexion qu'un composant d'application maintient en activité dans les limites de transaction et de méthode. Vous pouvez utiliser cette propriété pour déboguer des incidents de connexion, mais le suivi des descripteurs peut être à l'origine de problèmes de performances significatifs lors de l'exécution.

Si la propriété Gérer les descripteurs placés en cache est sélectionnée dans la console d'administration et que vous la désélectionnez, la zone n'est plus visible pour les ressources en version 7.0 ou ultérieure du serveur d'applications. Cette zone s'affiche uniquement si la propriété manageCachedHandles a la valeur true dans le fichier resources.xml. Pour rendre la zone disponible, remplacez la valeur false de l'entrée manageCachedHandles par true dans le fichier resources.xml ou entrez la commande Jython suivante via l'outil wsadmin :
AdminConfig.modify(myDataSourceVariable, '[[manageCachedHandles "true"]]')
Remarque : Pour toute ressource en cours d'exécution sur la version 6.x du serveur d'applications, la propriété Gérer les descripteurs placés en cache est toujours visible. Par exemple, si vous avez un noeud qui est à la version 6.1, l'entrée dans le fichier resources.xml n'a aucune incidence sur l'affichage de la zone dans la console d'administration.
Il existe une autre méthode permettant de déboguer les problèmes : utilisez les alertes de diagnostic inter composants et multiunités d'exécution pour détecter les violations dans le modèle de programmation JCA (Java Connector Architecture). Pour activer ces alertes, sélectionnez ces options dans le panneau Serveurs > Serveurs d'applications > serveur_applications > Performances > Configuration de l'assistant des performances et du diagnostic > Configuration des conseils de performances et de diagnostic. Ces alertes forcent le gestionnaire de connexions à gérer les descripteurs placés en cache, détectent les conditions de connexion et envoient des alertes.
Remarque : Pour que ces alertes soient actives, vous devez également sélectionner Activer la structure de l'assistant des performances et du diagnostic (Assistant des performances de la phase d'exécution) dans le panneau Serveurs > Serveurs d'applications > serveur_applications > Performances > Configuration de l'assistant des performances et du diagnostic.

Journaliser les contextes de transaction manquants

Indique si le conteneur enregistre une entrée dans le journal des activités lorsqu'une application obtient une connexion sans contexte de transaction. Il s'agit d'exceptions aux conditions préalables de la connexion du modèle de programmation Java Platform, Enterprise Edition (Java EE).

Source de données non transactionnelle

Indique que le serveur d'applications ne répertorie pas les connexions de cette source de données dans les transactions locales ou globales. Les applications doivent appeler explicitement setAutoCommit(false) si elles veulent démarrer une transaction locale sur la connexion et elles doivent valider ou annuler la transaction qui a été démarrée.
Eviter les incidents Eviter les incidents: Cette propriété doit être définie sur true dans de très rares cas, sauf lorsque une application JPA (Java Persistence API) requiert des sources de données JTA et non JTA. Cette propriété doit être définie sur true pour les sources de données non JTA.gotcha

Utilisez le modèle de contrôle des exceptions WebSphere Application Server

Indique que le serveur d'applications utilise la fonction de mappage d'erreurs définie dans l'auxiliaire de magasin de données pour identifier les erreurs. Il ne remplace les exceptions émises par le pilote JDBC par les exceptions définies dans la mappe d'erreurs de l'auxiliaire du magasin de données.

Utilisez le modèle de mappage d'exceptions WebSphere Application Server

Indique que le serveur d'applications utilise la fonction de mappage d'erreurs définie dans l'auxiliaire de magasin de données pour identifier les erreurs et qu'il remplace les exceptions émises par le pilote JDBC par les exceptions définies dans la mappe d'erreurs de l'auxiliaire de magasin de données.

Remarque : Ce modèle de détection des erreurs fonctionne avec JDBC version 3.0 et versions antérieures.

Valider les nouvelles connexions

Indique si le gestionnaire de connexions teste la nouvelle connexion créée à la base de données.

Nombre de tentatives

Indique le nombre de fois que la connexion initiale à la base de données doit être retestée après l'échec de la première opération de test préalable.

Intervalle entre les nouvelles tentatives

Si vous sélectionnez Valider les nouvelles connexions, cette option indique la durée, en secondes, durant laquelle le serveur d'applications attend avant de faire une nouvelle tentative de connexion si la connexion d'origine échoue.

Valider les connexions en pool existantes

Indique si le gestionnaire de connexions teste la validité des connexions mises en pool avant de les renvoyer aux applications.

Intervalle entre les nouvelles tentatives

Si vous sélectionnez Inspecter les connexions en pool existantes, cette option indique la durée en secondes à attribuer au pilote JDBC pour la validation d'une connexion.

Validation par pilote JDBC

Indique que le serveur d'applications utilise le pilote JDBC pour valider les connexions. Le fournisseur JDBC doit prendre en charge JDBC version 4.0 ou ultérieure pour utiliser cette option. Cette option n'est disponible que si l'option Valider les nouvelles connexions ou Valider les connexions en pool existantes est sélectionnée.

Délai d'expiration

Spécifie le délai d'attente, en secondes, pour tester les connexions, nouvelles ou regroupées par le serveur d'applications, à la base de données. Si le délai expire avant la validation, la connexion est considérée comme inutilisable. Si de nouvelles tentatives sont configurées, la valeur totale du délai s'applique à chaque tentative. Une valeur égale à 0 indique que le pilote JDBC n'impose aucun délai d'attente aux tentatives de validation.
Remarque : Cette option est disponible uniquement pour les pilotes JDBC compatibles JDBC 4.0.

Validation par chaîne SQL (obsolète)

Spécifie l'instruction SQL que le serveur d'applications envoie à la base de données pour tester la connexion. Utilisez une requête qui n'aura que peu d'impact sur les performances. Cette option n'est disponible que si l'option Valider les nouvelles connexions ou Valider les connexions en pool existantes est sélectionnée.

Optimisation du masque get/use/close avec un regroupement hétérogène

Optimise la source de données pour les applications qui utilisent le masque de connexion get/use/close. Cette optimisation permet au pool de connexions correspondant à la source de données de partager des connexions se trouvant dans la même transaction. Avec ce masque d'optimisation, vous pouvez partager une connexion lors d'une transaction même lorsque des connexions utilisent des propriétés de connexion différentes.

Si vous utilisez la fonction de regroupement hétérogène, vous devez tout d'abord étendre la définition de la source de données afin de pouvoir spécifier plusieurs propriétés personnalisées ou autoriser les applications à remplacer les propriétés non centrales de la source de données. Pour plus d'informations sur l'extension des sources de données, consultez les informations relatives à l'extension des définitions de source de données DB2 au niveau application.

Remarque : Cette zone est disponible uniquement pour les sources de données DB2.

Intervalle entre des tentatives de redirection du client

Indique le délai d'attente, en secondes, entre les tentatives de redirection du client.

Remarque : Cette zone est disponible uniquement pour les sources de données DB2.

Nombre maximum de tentatives de redirection du client

Indique le nombre maximum de tentatives de connexion de la fonction de redirection automatique du client en cas d'échec de la connexion principale au serveur. La propriété est utilisée uniquement lorsque Intervalle entre des tentatives de redirection du client est définie.

Remarque : Cette zone est disponible uniquement pour les sources de données DB2.

Autres noms de serveur

Indique la liste des autres noms de serveur pour le serveur DB2. Si plusieurs autres noms de serveur sont spécifiés, ils doivent être séparés par des virgules. par exemple :
host1,host2
Remarque : Cette zone est disponible uniquement pour les sources de données DB2.

Autres numéros de port

Indique la liste des autres ports du serveur pour le serveur DB2. Si plusieurs autres ports de serveur sont spécifiés, ils doivent être séparés par des virgules. Par exemple :
5000,50001
Remarque : Cette zone est disponible uniquement pour les sources de données DB2.

Nom JNDI de la liste des serveurs de redirection client

Indique le nom JNDI employé pour lier la liste des serveurs de redirection client DB2 à l'espace de nom JNDI. Le serveur de base de données DB2 utilise ce nom pour chercher la liste de noms de serveur lorsque les informations sur les autres serveurs ne sont pas déjà en mémoire. Cette option n'est pas prise en charge par les sources de données de type 2.

Remarque : Cette zone est disponible uniquement pour les sources de données DB2.

Déconnecter la liste de redirection du client de JNDI

Utilisé uniquement avec les tests de connexions. Lorsque cette option a pour valeur true, le nom JNDI de la liste de serveurs de redirection client est déconnecté de l'espace de nom JNDI après un test de connexion.

Remarque : Cette zone est disponible uniquement pour les sources de données DB2.

Icône indiquant le type de rubrique Rubrique de référence



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=udat_jdbcdatasorprops
Nom du fichier : udat_jdbcdatasorprops.html