Réglage des pools de connexions
L'utilisation de pools de connexions permet de minimiser le délai de gestion des connexions et de réduire les tâches de développement liées à l'accès aux données. A chaque fois qu'une application essaye d'accéder à un magasin dorsal (comme une base de données), des ressources doivent créer, gérer et libérer une connexion au magasin de données. Pour diminuer l'effort que les ressources de l'application doivent déployer à cause de ce processus, le serveur d'applications permet aux administrateurs d'établir un pool de connexions dorsales que les applications peuvent partager sur un serveur d'applications. La mise en pool des connexions répartit le coût d'établissement des connexions entre plusieurs demandes utilisateur, préservant ainsi les ressources de l'application pour d'autres demandes.
Pourquoi et quand exécuter cette tâche

Procédure
- Empêcher un blocage de connexion. Un blocage peut se produire si l'application nécessite plusieurs connexions simultanées par unité d'exécution et que la taille du pool de connexions à la base de données n'est pas assez importante pour le nombre d'unités d'exécution. Supposez que chacune des unités d'exécution d'application nécessite deux connexions simultanées à la base de données et que le nombre d'unités d'exécution soit égal à la taille maximale du pool de connexions. Un blocage peut se produire lorsque les deux conditions suivantes sont vérifiées :
- chaque unité d'exécution a sa première connexion à la base de données, et toutes sont en cours d'utilisation,
- chaque unité d'exécution attend une seconde connexion à la base de données et aucune ne sera disponible car toutes les unités sont bloquées.
Pour éviter le blocage, le nombre maximal de connexions pour le pool de connexions de la base de données doit être augmenté d'au moins un point. Ainsi, au moins l'une des unités d'exécution obtient une seconde connexion de base de données et cela évite de générer un interblocage.
Pour éviter de manière générale un blocage, codez vos applications de telle sorte qu'elles n'utilisent qu'une seule connexion par unité d'exécution. Si l'application est codée pour demander des connexions simultanées de type C à la base de données par unité d'exécution, le pool de connexions doit prendre en charge au moins le nombre de connexions ci-après (T représentant le nombre maximal d'unités de connexions permis) :T * (C - 1) + 1
Les paramètres du pool de connexions sont directement liés au nombre de connexions pouvant être prises en charge par le serveur de bases de données. Si vous augmentez le nombre maximal de connexions dans le pool et non les paramètres correspondants dans la base de données, l'application peut échouer. Les erreurs d'exception SQL résultantes s'affichent dans les emplacements suivants :Le plus souvent, un blocage de connexion survient car le même pool de connexions est utilisé par les deux servlets et par les beans EJB (Enterprise JavaBeans) lorsqu'un servlet appelle le bean directement ou indirectement. Par exemple, un servlet qui obtient une connexion JMS depuis le pool de connexions envoie un message à un bean géré par message (MDB) et attend une réponse. Comme le bean géré par message est configuré pour utiliser le même pool de connexions que le servlet, une autre connexion du pool est requise pour que le bean géré par message puisse envoyer une réponse au servlet. Les servlets et les bean enterprise ne partagent pas le même pool de connexions. C'est une situation classique d'unités d'exécution concurrentes dans laquelle C=2 et T indique la taille maximale des pools d'unités d'exécution EJB et du servlet.Fichier stderr.log
SYSOUT du processus servant
- Désactivez le regroupement de connexions.
- Pour les adaptateurs de ressources relationnels (RRA), ajoutez la propriété
personnalisée disableWASConnectionPooling pour vos sources de
données.
- Cliquez sur JDBC > Sources de données.
- Cliquez sur le nom de la source de données à configurer.
- Cliquez sur Propriétés personnalisées sous l'en-tête Propriétés supplémentaires.
- Cliquez sur Nouveau.
- Dans les zones requises, indiquez les informations suivantes :
- Nom : disableWASConnectionPooling
- Valeur : true
- Pour les autres adaptateurs de ressources, consultez les spécifications de liaison
de cet adaptateur de ressources pour configurer vos applications afin de désactiver le regroupement
d'applications.
- Désactivez le regroupement de connexions par programmation via l'adaptateur de ressources.
- Le serveur d'applications optimise le code suivant afin de détecter l'exception javax.resource.NotSupportedException
et de désactiver une mise en pool de connexions :
_managedFactory.matchManagedConnections(s,subject,cri); // 169059 174269 } catch(javax.resource.NotSupportedException e){
- Pour les adaptateurs de ressources relationnels (RRA), ajoutez la propriété
personnalisée disableWASConnectionPooling pour vos sources de
données.
- Activez l'inscription différée.
Dans l'environnement du serveur d'applications, l'inscription différée fait référence à une technique dans laquelle le serveur d'applications attend que la connexion soit utilisée avant de l'inscrire dans la portée de l'unité de travail de l'application (UOW).
Considérez l'exemple d'inscription différée suivant :- Un composant d'application utilisant l'inscription différée appelle la méthode getConnection à partir d'une transaction globale.
- Le composant d'application n'utilise pas la connexion immédiatement.
- Lorsque l'application lance l'appel pour l'utilisation initiale de la connexion, le gestionnaire de transactions l'intercepte.
- Le gestionnaire de transactions inscrit la ressource XA de la connexion et appelle la méthode XAResource.start.
- Le gestionnaire de connexions associé à la ressource XA envoie l'appel à la base de données.
L'inscription différée offre de meilleures performances en cas d'obtention d'une connexion qui n'est pas utilisée dans la portée UOW. La technique enregistre le coût de participation à la transaction jusqu'à l'unité de travail dans laquelle doit se produire la participation.
Consultez le fournisseur d'adaptateurs de ressources pour savoir si l'adaptateur de ressources fournit cette fonctionnalité. L'adaptateur de ressources relationnelles du serveur d'applications prend en charge l'inscription différée automatiquement.
Incorporation d'une inscription différée dans le code :
La spécification Java™ Platform, Enterprise Edition (Java EE) Connector Architecture (JCA) version 1.5 et versions ultérieures appelle la technique d'inscription différée optimisation par inscription différée dans les transactions. Ce support est fourni par une interface de marquage (LazyEnlistableManagedConnection) et une méthode dans le gestionnaire de connexions (LazyEnlistableConnectionManager()):package javax.resource.spi; import javax.resource.ResourceException; import javax.transaction.xa.Xid; interface LazyEnlistableConnectionManager { // application server void lazyEnlist(ManagedConnection) throws ResourceException; } interface LazyEnlistableManagedConnection { // resource adapter }
- Contrôlez le partage du pool de connexions. Vous pouvez utiliser la propriété personnalisée de pool de connexions defaultConnectionTypeOverride ou globalConnectionTypeOverride d'une fabrique de connexions ou d'une source de données pour contrôler le partage de connexion :
- La propriété defaultConnectionTypeOverride modifie la valeur de partage par défaut d'un pool de connexions. Cette propriété vous permet de contrôler le partage de connexion pour des recherches directes. Si les références de ressource sont configurées pour cette source de données ou cette fabrique de connexions, les configurations de référence de données sont prioritaires par rapport aux paramètres de propriété defaultConnectionTypeOverride. Par exemple, si une application effectue des recherches directes et que des connexions non partagées sont nécessaires, affectez à la propriété defaultConnectionTypeOverride la valeur unshared.
- La valeur spécifiée pour la propriété personnalisée globalConnectionTypeOverride a la priorité sur tous les autres paramètres de partage de connexion. Par exemple, si vous lui affectez la valeur unshared, toutes les demandes de connexion ne sont pas partagées pour les recherches directes et les recherches de références de ressources. Cette propriété permet de tester rapidement l'impact du passage de l'état Non partagé de toutes les connexions d'une source de données ou d'une fabrique de connexions à l'état Partagé sans changer le paramétrage des références de ressources.
Si vous définissez des valeurs pour les propriétés defaultConnectionTypeOverride et globalConnectionTypeOverride, seules les valeurs définies pour la propriété globalConnectionTypeOverride sont utilisées pour déterminer le type de partage de connexion.
Pour ajouter ces nouvelles propriétés personnalisées aux paramètres d'une source de données ou d'un pool de connexions de fabrique de connexions, une nouvelle propriété personnalisée doit être créée. Pour ajouter une de ces propriétés à une source de données, utilisez la console d'administration. Cliquez sur Ressources > JDBC > Sources de données. Sélectionnez votre source de données dans la liste, puis cliquez sur Propriétés personnalisées > Propriétés de pool de connexions > Propriétés personnalisées de pool de connexions > Nouveau. Pour les autres fabriques de connexions J2C ou JMS, accédez à la définition de fabrique de connexions dans la console d'administration. Sélectionnez ensuite Propriétés supplémentaires > Pool de connexions > Propriétés personnalisées du pool de connexions > Nouveau. Indiquez maintenant defaultConnectionTypeOverride ou globalConnectionTypeOverride dans la zone Nom, et shared ou unshared dans la zone Valeur.Important : Les propriétés doivent être définies dans la zone Propriétés personnalisées du pool de connexions alors que les Propriétés personnalisées générales ne doivent pas être définies sur la fabrique de connexions ou la source de données. Exécutez une action automatique d'atténuation si le pool de connexion ne peut pas établir une connexion à son gestionnaire de ressources configuré.
En utilisant les propriétés failureNotificationActionCode et failureThreshold, un pool de connexions peut être configuré pour que, lorsqu'une fabrique de connexion ne peut pas établir une connexion à son gestionnaire de ressources configuré, une action d'atténuation autonome soit exécutée par l'environnement exécution WebSphere Application Server for z/OS pour réduire l'impact de l'échec sur l'utilisateur. Lorsqu'une fabrique de connexion peut établir de nouveau une connexion au gestionnaire de ressources configuré, l'action d'atténuation autonome est inversée. Cette situation existe, par exemple, lorsque l'exécution peut émettre une commande "pause listeners" pour le serveur avec la ressource défaillante pour empêcher l'acceptation d'un nouveau travail par le serveur. Lorsqu'il est combiné avec un front-end haute disponibilité, le nouveau travail peut être routé vers d'autres serveurs d'un cluster.
Une notification est envoyée à l'environnement d'exécution z/OS lorsqu'une source de données ou une fabrique de connexions particulière a atteint une valeur de seuil d'incidents par défaut ou spécifiée. La notification d'échec contient un code d'action défini qui détermine comment l'exécution répond à la notification. Voir la rubrique Propriétés d'un pool de connexions pour les définitions de code d'action.
Pour pouvoir utiliser ces propriétés, vous devez les définir comme propriétés personnalisées du pool de connexions. Pour ce faire, vous pouvez vous servir de la console d'administration : cliquez sur Fournisseurs JDBC > Sources de données > Pools de connexions > Propriétés personnalisées > Nouveau. Définissez ensuite failureNotificationActionCode ou failureNotification dans la zone Nom et la valeur appropriée dans la zone Valeur.
Pour plus d'informations sur les paramètres de ces propriétés personnalisées, voir la rubrique Propriétés personnalisées d'un pool de connexions.
- Annulez les connexions.
Les paramètres d'intervalle de régulation et de délai d'attente inutilisés ne provoquent pas l'annulation des connexions inactives ou inutilisées si la région serviteur est inactive. Cette situation peut provoquer une mise en attente de certaines connexions DB2 plus longue que nécessaire.
Si vous préférez que les connexions soient annulées à l'heure spécifiée par une combinaison de paramètres d'intervalle de régulation et de délai d'attente inutilisés, même si cette préférence peut provoquer la réactivation d'une région serviteur inactive, vous pouvez ajouter la propriété personnalisée nondeferredreaper à vos paramètres de source de données de fournisseur de pilote JDBC. Lorsque vous ajoutez cette propriété personnalisée, les connexions sont annulées à l'heure indiquée par une combinaison de paramètres d'intervalle de régulation et de délai d'attente inutilisés.
Pour ajouter cette propriété personnalisée à vos paramètres de source de données du fournisseur du pilote JDBC, dans la console d'administration, cliquez sur Ressources > Fournisseurs JDBC > Fournisseur de pilote DB2 Universal JDBC > Sources de données > source_données > Propriétés personnalisées > Nouveau. Indiquez ensuite nondeferredreaper dans la zone Nom, true dans la zone Valeur et java.lang.Boolean dans la zone Type. Ce nouveau paramètre ne prend effet que lorsque vous redémarrez le serveur utilisant cette source de données.
Eviter les incidents: L'activation d'une région serviteur inactive dans le but d'annuler une connexion inutilisée peut provoquer une utilisation supplémentaire et parfois indésirable de l'unité centrale. Le message d'avertissement suivant peut également être consigné et doit être ignoré :
gotchaDSRA8200W: DataSource Configuration: DSRA8020E: Warning: The property 'nondeferredreaper' does not exist on the DataSource classcom.ibm.db2.jcc.DB2ConnectionPoolDataSource.
- Purgez les pools de connexions en fonction de la règle de purge.
Lorsque le modèle de détection des erreurs de pool de connexions est configuré sur le mappage des exceptions, l'exception de connexion périmée indique que la connexion n'est plus valide.
En général, lorsqu'une StaleConnectionException découle du processus de mappage d'exception, un événement d'erreur de connexion est déclenché, puis le pool de connexions est purgé. Cependant, dans ce cas, le SCE est instancié, le code existant n'est pas doté de la fonctionnalité de déclenchement de l'événement d'erreur de connexion et le pool n'est pas purgé. Quand les connexions prennent fin côté base de données lors de la demande d'une nouvelle connexion, le pilote émet une XAException. Si le résultat est errorDetectionModel=ExceptionMapping, un événement d'erreur de connexion est déclenché de sorte que le pool de connexion est purgé en fonction de la règle de purge.
Pour ajouter cette propriété personnalisée à vos paramètres de source de données du fournisseur du pilote JDBC, dans la console d'administration, cliquez sur Ressources > Fournisseurs JDBC > Fournisseur de pilote DB2 Universal JDBC > Sources de données > source_données > Propriétés personnalisées > Nouveau. Indiquez ensuite fireCEEventOnSCE dans la zone Nom, true dans la zone Valeur et java.lang.Boolean dans la zone Type. Ce nouveau paramètre ne prend effet que lorsque vous redémarrez le serveur utilisant cette source de données.
Le code RRA WebSphere a été modifié de sorte que le pool soit purgé correctement quand une StaleConnectionException se produit lorsque le mappage d'exception (ExceptionMapping) est utilisé comme modèle de détection d'erreur.
Sous-rubriques


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tdat_conpoolman
Nom du fichier : tdat_conpoolman.html