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 :
Taille de la cache d'instructions

Indique le nombre d'instructions par connexion pouvant être placées en mémoire cache. Le serveur d'application 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 possibles qui peuvent être placées en mémoire cache sur une connexion donnée au cours de la vie du serveur. Si vous définissez cette valeur de taille de 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] [iSeries] 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'application mette en mémoire cache une application particulière, configurez l'indice de regroupement de l'instruction sur false. Le serveur d'application ne met pas une instruction en mémoire cache si l'indice de regroupement est défini sur 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 d'optimiser ainsi la taille du cache.

Type de données Entier
Valeur 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

Si cette option est sélectionnée, le serveur d'applications détecte l'existence d'un accès par plusieurs unités d'exécution.

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 connexion 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 de la méthode com.ibm.websphere.rsadapter.DataStoreHelper#doConnectionSetupPerTransaction(...)

La réauthentification de connexion peut augmenter les performances en réduisant la surcharge liée à l'ouverture et à la fermeture des connexions, en particulier pour les applications qui demandent souvent des connexions avec des noms d'utilisateur et des mots de passe différents.
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.

Si cette option est sélectionnée, le serveur d'applications permet au service JMS (Java messaging service) d'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.

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 d'une surcharge de performances 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 de la version 7.0 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, changez la valeur de l'entrée manageCachedHandles de false en true dans le fichier resources.xml ou entrez la commande Jython suivante à partir de l'outil wsadmin :
AdminConfig.modify(myDataSourceVariable, '[[manageCachedHandles "true"]]')
Configurations prises en charge : 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 sera 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.sptcfg
Il existe une autre méthode permettant de déboguer les incidents : 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 Connectivity 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 doivent valider ou annuler la transaction qui a été démarrée.
Eviter les incidents : Cette propriété doit être définie sur true dans de très rares cas, toutefois JPA (Java Persistence API) requiert des sources de données JTA et non-JTA.gotcha
Utiliser 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. 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.

Utiliser 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.

Configurations prises en charge : Ce modèle de détection des erreurs fonctionne avec JDBC version 3.0 et versions antérieures.sptcfg
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.

Eviter les incidents : Pour une source de données Oracle, la validation par pilote JDBC figure dans la console d'administration uniquement après que la propriété validateNewConnectionTimeout est ajoutée aux propriétés personnalisées des propriétés de la source de données WebSphere Application Server. La propriété $validateNewConnectionTimeout est utilisée pour la validation du pilote JDBC 4.0 et elle peut être spécifiée en utilisant la console d'administration.gotcha
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.
Configurations prises en charge : Cette option est disponible uniquement pour les pilotes JDBC compatibles JDBC 4.0.sptcfg
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.

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

Indique que le serveur d'applications utilise le masque get/use/close/connection. Il permet au serveur d'applications de regrouper les connexions pour partager celles de la même transaction. Ce masque d'optimisation permet à une connexion d'être partagée au cours d'une transaction même lorsque les connexions utilisent des propriétés de connexion différentes.

La fonction de regroupement hétérogène permet d'étendre la définition de la source de données pour que vous puissiez spécifier plusieurs propriétés personnalisées ou autoriser les applications à substituer les propriétés non centrales de la source de données.

Configurations prises en charge : Cette zone est disponible uniquement pour les sources de données DB2.sptcfg
Intervalle entre des tentatives de redirection du client

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

Configurations prises en charge : Cette zone est disponible uniquement pour les sources de données DB2.sptcfg
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.

Configurations prises en charge : Cette zone est disponible uniquement pour les sources de données DB2.sptcfg
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
Configurations prises en charge : Cette zone est disponible uniquement pour les sources de données DB2.sptcfg
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
Configurations prises en charge : Cette zone est disponible uniquement pour les sources de données DB2.sptcfg
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 n'est pas déjà en mémoire. Cette option n'est pas prise en charge par les sources de données de type 2.

Configurations prises en charge : Cette zone est disponible uniquement pour les sources de données DB2.sptcfg
Déconnecter la liste de redirection du client de JNDI

Utilisé uniquement avec les tests de connexions. Lorsqu'il est défini sur true, le nom JNDI de la liste de serveurs de redirection est déconnecté de l'espace nom JNDI name après qu'un test de connexion ait été effectué.

Configurations prises en charge : Cette zone est disponible uniquement pour les sources de données DB2.sptcfg



Les liens marqués (en ligne) requièrent un accès à Internet.

Concepts associés
Tâches associées
Référence associée
Propriétés personnalisées


Nom du fichier : udat_jdbcdatasorprops.html