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

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.

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.

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.

Lorsqu'elle est activée, le message d'avertissement suivant est consigné 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.

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

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 : 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

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.

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.

AdminConfig.modify(myDataSourceVariable, '[[manageCachedHandles "true"]]')

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

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.

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.

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

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.

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.

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

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.

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.

Eviter les incidents : Pour une source de données Oracle, la propriété Validation par pilote JDBC figure dans la console d'administration uniquement après l'ajout de la propriété validateNewConnectionTimeout aux propriétés personnalisées de la source de données. La propriété validateNewConnectionTimeout est utilisée pour la validation du pilote JDBC 4.0 et elle peut être spécifiée à l'aide de la console d'administration.gotcha

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.

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.

Indique le délai d'attente, en secondes, entre les 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.

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.

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.