Cette page permet de configurer les paramètres du pool de connexions.
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) |
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.
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.
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.
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.
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. |
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.
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) |
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) |
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) |
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) |
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 |
|
Intervalle |
|
Les liens marqués (en ligne) requièrent un accès à Internet.