Paramètres du pool de connexions

Cette page permet de configurer les paramètres du pool de connexions.

Cette page de la console d'administration est commune aux sources de données JDBC et aux fabriques de connexions JMS (fabriques de connexions unifiées, de file d'attente ou de rubrique). Son chemin d'accès dépend du type de ressource, mais il suffit en général de sélectionner une instance du type de ressource et de cliquer ensuite sur Pool de connexions pour l'afficher. Par exemple :
Eviter les incidents : Le regroupement de connexions n'est pas pris en charge dans un client d'application. Le client d'application appelle directement la base de données et ne passe pas par une source de données. Pour utiliser la demande getConnection() à partir du client d'application, configurez le fournisseur JDBC dans les descripteurs de déploiement du client d'application à l'aide de Rational Application Developer ou d'un outil d'assemblage. La connexion est établie entre le client d'application et la base de données. Les clients d'application ne possèdent pas de pool de connexions mais vous pouvez configurer les paramètres de fournisseur JDBC dans les descripteurs de déploiement du client.gotcha
Délai d'expiration de connexion

Spécifie le délai, en secondes, au terme duquel une demande de connexion expire et une exception ConnectionWaitTimeoutException est émise.

Cette valeur indique, en secondes, le délai d'attente d'une demande de connexion lorsqu'aucune connexion n'est disponible dans le pool libre et qu'aucune connexion ne peut être créée. Cette impossibilité est généralement due au fait que le nombre maximal de connexions autorisées dans ce pool est atteint.

Par exemple, si le paramètre Délai d'expiration de connexion a la valeur 300 et que le nombre maximal de connexions est utilisé, le gestionnaire du pool attend 300 secondes qu'une connexion physique devienne disponible. Si, passé ce délai, aucune connexion physique n'est disponible, le gestionnaire du pool lance une exception ConnectionWaitTimeout. Il n'y a généralement pas lieu de retenter la méthode getConnection() car si une attente plus longue est nécessaire pour l'obtention d'une connexion, vous devez augmenter la valeur du paramètre Délai d'expiration de connexion. Si une exception ConnectionWaitTimeout est interceptée par l'application, étudiez la syntaxe attendue du pool de connexions de l'application et réglez en conséquence les paramètres du pool de connexions et de la base de données.

Si le paramètre Délai d'expiration de connexion a la valeur 0, le gestionnaire du pool attend aussi longtemps que nécessaire qu'une connexion devienne disponible. Cela se produit lorsque l'application a traité une transaction et renvoie une connexion au pool ou lorsque le nombre de connexions passe sous le seuil du paramètre Nombre maximal de connexions, ce qui autorise la création d'une connexion physique.

Si le paramètre Nombre maximal de connexions est associé à la valeur 0, ce qui autorise un nombre illimité de connexions physiques, la valeur du délai d'expiration de connexion est ignorée.

Type de données Entier
Unité Secondes
Valeur par défaut é180
Intervalle 0 à max (nombre entier)
Nombre maximal de connexions

Spécifie le nombre maximal de connexions physiques qui peuvent être créées dans le pool.

Il s'agit de connexions physiques à une ressource dorsale. Une fois ce nombre atteint, aucune nouvelle connexion physique n'est créée et le demandeur doit attendre qu'une connexion physique en cours d'utilisation soit renvoyée au pool ou qu'une exception ConnectionWaitTimeoutException soit lancée. Par exemple, si le paramètre Nombre maximal de connexions a la valeur 5 et qu'il y a cinq connexions physiques en cours d'utilisation, le gestionnaire de pool attend qu'une connexion physique se libère pendant la durée spécifiée par le paramètre Délai d'expiration de connexion.

Le fait de connaître le nombre de pools de connexions qui sont susceptibles de demander des connexions du système dorsal (tel qu'une base de données DB2 ou un serveur CICS) vous aide à déterminer une valeur pour la propriété Nombre maximal de connexions.

[AIX Solaris HP-UX Linux Windows] [iSeries] Dans le cas de plusieurs serveurs d'applications autonomes utilisant la même configuration de source de données ou la même configuration de fabrique de connexions J2C, un pool de connexions physique distinct existe pour chaque serveur. Si vous clonez ces mêmes serveurs d'applications, WebSphere Application Server implémente un pool de connexions distinct pour chaque clone.

[z/OS] Prenez en considération le nombre de servants qui accèdent à la même ressource ; lors de l'exécution, ce nombre multiplie essentiellement la valeur du paramètre Nombre maximal de connexions. Si les servants appellent la même configuration de source de données JDBC ou la même configuration de fabrique de connexions J2C, WebSphere Application Server implémente un pool de connexions physique correspondant pour chaque servant. Par conséquent, le même pool de connexions existe, indépendamment, pour chaque serveur. La valeur du paramètre Nombre maximal de connexions s'applique à chacun de ces pools.

[AIX Solaris HP-UX Linux Windows] [iSeries] Tous ces pools de connexions correspondent à la même source de données ou à la même configuration de fabrique de connexions. Par conséquent, ils sont tous susceptibles de demander simultanément des connexions de la même ressource dorsale. La seule valeur du paramètre Nombre maximal de connexions que vous définissez dans ce panneau de la console s'applique à chacun de ces pools de connexions. En conséquence, le fait d'attribuer une valeur élevée au paramètre Nombre maximal de connexions peut donner lieu à une charge de demandes de connexion trop forte pour la ressource dorsale.

[z/OS] Chaque application qui requiert la source de données ou la fabrique de connexions dans ces servants est susceptible d'essayer d'utiliser la ressource simultanément. Par conséquent, les pools de connexions correspondants requièrent simultanément des connexions du même système dorsal. N'attribuez pas une valeur au paramètre Nombre maximal de connexions qui puisse amener la charge des demandes de connexion à surcharger votre base de données ou un autre système d'information d'entreprise (EIS).

Type de données Entier
Valeur par défaut 10
Intervalle 0 à maximum (nombre entier)

Si le paramètre Nombre maximal de connexions est réglé sur 0, la valeur du délai d'expiration de connexion est ignorée.

Conseil : Pour optimiser les performances, définissez pour le pool de connexions une valeur inférieure au nombre maximal de connexions du pool d'unités d'exécution du conteneur Web. Popur définir ce paramètre, accédez à Serveurs > Types de serveurs > Serveurs d'applications WebSphere > serveur > Pool d'unités d'exécution et modifiez la propriété WebContainer. Des valeurs basses (entre 10 et 30 connexions) permettent de meilleures performances que des valeurs hautes (100, par exemple).

Vous pouvez utiliser Tivoli Performance Viewer pour déterminer le nombre maximal de connexions dans un pool. Si le nombre d'unités simultanément en attente est supérieur à 0, mais que la charge de l'unité centrale n'est pas proche de 100 %, vous pouvez envisager d'augmenter la taille du pool de connexions. Si la valeur Pourcentage utilisé est constamment faible, pour une charge de travail normale, diminuez le nombre de connexions du pool.

Nombre minimal de connexions

Spécifie le nombre minimal de connexions physiques à maintenir.

Si la taille du pool de connexions est inférieure ou égale à la taille minimale autorisée, l'unité d'exécution Délai d'inutilisation n'élimine pas les connexions physiques. Cependant, aucune connexion n'est créée dans le pool afin que la taille du pool ne dépasse pas la valeur minimale autorisée. De plus, si vous définissez une valeur pour Délai dépassé, les connexions arrivées à expiration sont éliminées, quelle que soit la taille minimale du pool de connexions.

Par exemple, si le paramètre Nombre minimal de connexions a pour valeur 3 et qu'une seule connexion physique est créée, cette connexion n'est pas supprimée suite au dépassement du délai d'inutilisation. De même, l'unité d'exécution ne crée pas automatiquement deux connexions physiques supplémentaires pour atteindre la valeur du paramètre Nombre minimal de connexions.

Type de données Entier
Valeur par défaut 1
Intervalle 0 à max (nombre entier)
Intervalle de ramassage

Indique l'intervalle, en secondes, entre chaque lancement de l'unité d'exécution de maintenance des pools.

Par exemple, si l'intervalle de ramassage a pour valeur 60, l'unité d'exécution de maintenance du pool s'exécutera toutes les minutes. L'intervalle de régulation a un impact sur l'exactitude des paramètres Délai d'inutilisation et Délai dépassé. Plus l'intervalle est court, plus ces paramètres peuvent être exacts. Si l'unité d'exécution de maintenance du pool est activée, réglez le délai de ramassage sur une valeur inférieure à celles des paramètres Délai d'inutilisation et Délai dépassé. Lorsque l'unité d'exécution de maintenance du pool s'exécute, elle élimine les connexions qui sont restées inutilisées plus longtemps que la valeur fixée par le paramètre Délai d'inutilisation, jusqu'à ce que le nombre de connexions spécifié par le paramètre Nombre minimal de connexions soit atteint. L'unité d'exécution de maintenant élimine également les connexions qui sont restées actives plus longtemps que la valeur spécifiée par le paramètre Délai dépassé.

L'intervalle de ramassage a également un impact sur les performances. Plus il est court, plus l'unité d'exécution de maintenance du pool est sollicitée, ce qui a pour conséquence de dégrader les performances.

Pour désactiver l'unité d'exécution de maintenance du pool, associez le délai de ramassage à la valeur 0 ou mettez à zéro les paramètres Délai d'inutilisation et Délai dépassé. La méthode recommandée pour désactiver l'unité d'exécution de maintenance du pool est d'associer le délai de ramassage à la valeur 0, auquel cas les paramètres Délai d'inutilisation et Délai dépassé sont ignorés. Cependant, si le délai d'inutilisation et le délai dépassé ont pour valeur 0, l'unité d'exécution de maintenance du pool s'exécute, mais seules les connexions physiques qui sont en dépassement de délai en raison d'un délai d'attente non nul sont éliminées.

Type de données Entier
Unité Valeur par défaut
Valeur par défaut 180
Intervalle 0 à max (nombre entier)
Délai d'inutilisation

Spécifie le délai, en secondes, au terme duquel une connexion inutilisée ou au repos est éliminée.

Pour des performances optimales, réglez le délai d'inutilisation sur une valeur plus grande que celle du délai de ramassage. Les connexions physiques inutilisées sont éliminées uniquement si le nombre de connexions dépasse la valeur du paramètre Nombre minimal de connexions. Par exemple, si la valeur du délai d'inutilisation est 120 secondes et que l'unité d'exécution de maintenance du pool est activée (délai de ramassage différent de 0), toute connexion physique qui reste inutilisée plus de deux minutes est éliminée.

La précision et les performances de ce délai dépendent de la valeur du délai de régulation. Pour plus d'informations, voir Intervalle de ramassage.

Type de données Entier
Unité Secondes
Valeur par défaut 1800
Intervalle 0 à max (nombre entier)
Délai dépassé

Spécifie le délai, en secondes, au terme duquel une connexion physique est éliminée.

Si le paramètre Délai dépassé a pour valeur 0, les connexions physiques actives sont conservées dans le pool indéfiniment. Pour optimiser les performances, définissez une valeur de délai dépassé supérieure au délai de ramassage, mais utilisez le délai dépassé uniquement si cela est nécessaire.

Pour la plupart des adaptateurs de ressources, le délai dépassé doit être égal à 0. Le délai dépassé doit être utilisé uniquement si vous savez qu'une connexion gérée va devenir obsolète. Par exemple, une connexion gérée IMS ne fonctionne plus lorsque son journal natif atteint une limite pour la connexion gérée. Si le journal est saturé en 30 minutes, définissez un délai dépassé de 25 minutes. Vous nettoyez ainsi la connexion gérée et libérez les ressources dorsales.

Dans un autre cas, si la valeur du délai dépassé est de 1 200 secondes et que le délai de ramassage est différent de 0, une connexion physique qui existe pendant 1 200 secondes (20 minutes) est éliminée du pool. sauf si la connexion est impliquée dans une transaction lorsque le délai dépassé est atteint, le serveur d'applications n'ignore pas la connexion tant que la transaction n'est pas terminée et que la connexion n'est pas fermée.

La précision et les performances de ce délai dépendent de la valeur du délai de régulation. Pour plus d'informations, voir Intervalle de ramassage.

Type de données Entier
Unité Secondes
Valeur par défaut 0
Intervalle 0 à max (nombre entier)
Règle de purge

Spécifie comment purger les connexions périmées (stale) ou présentant une erreur irrémédiable.

Les valeurs possibles sont Totalité du pool et Connexion défaillante uniquement.

Type de données Chaîne
Valeurs par défaut
  • Totalité du pool pour les fabriques de connexions J2C et les fabriques de connexions liées à JMS
  • Totalité du pool pour les sources de données WebSphere version 4.0
  • Totalité du pool pour les source de données de la version actuelle, que vous créez via la console d'administration
  • Totalité du pool pour les source de données de la version actuelle que vous scriptez à l'aide des commandes wsadmin AdminConfig en appelant des modèles JDBC générés dans WebSphere Application Server (pour plus d'informations sur la commande createUsingTemplate, voir l'article "Commands for the AdminConfig object" du centre de documentation)
  • Connexion défaillante uniquement pour les sources de données que vous scriptez dans wsadmin sans appeler de modèles JDBC
:
Intervalle
Totalité du pool
Toutes les connexions figurant dans le pool sont marquées comme périmées. Toute connexion qui n'est pas en cours d'utilisation est immédiatement fermée. Une connexion en cours d'utilisation est fermée et une exception de connexion périmée est générée lors de l'opération suivante sur cette connexion. Les demandes getConnection() émises subséquemment par l'application conduisent à l'ouverture de nouvelles connexions à la base de données. Lorsque cette règle de purge est utilisée, il existe une possibilité que certaines connexions du pool soient fermées inutilement parce qu'elles ne sont pas périmées. Cependant, la probabilité d'une telle situation reste très faible. Dans la plupart des cas, la règle de purge Totalité du pool est le meilleur choix.
FailingConnectionOnly
Seule la connexion à l'origine de l'exception de connexion périmée est fermée. Bien que ce choix permette d'éviter que des connexions valides ne soient fermées inutilement, il a pour inconvénient de rendre la reprise plus compliquée du point de vue de l'application. Comme la connexion défaillante est la seule a être fermée, il existe une très forte probabilité que la demande getConnection() suivante de l'application renvoie une connexion du pool qui est également périmée, ce qui conduit à la génération d'autres exceptions de connexion périmée.

La fonction de prétest de connexion tente d'isoler une application à partir de connexions mises en pool qui ne sont pas valides. En cas de panne d'une ressource dorsale, telle qu'une base de données, il peut subsister des connexions non valides dans le pool disponible. Ceci est particulièrement vrai quand la règle de nettoyage est failingConnectionOnly ; la connexion défaillante est alors retirée du pool. Selon la panne, certaines connexions du pool peuvent ne pas être valides.




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

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


Nom du fichier : udat_conpoolset.html