Mise en pool des 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 limiter l'effort que ce processus peut demander aux ressources de l'application, Server 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.
Le serveur d'applications prend en charge les API JDBC 4.0 pour la mise en pool des connexions et leur réutilisation. Le pool de connexions est utilisé pour acheminer les appels JDBC au sein de l'application, mais aussi comme moyen pour les beans enterprise d'accéder à la base de données.
Avantages de la mise en pool des connexions
La mise en pool des connexions peut améliorer le temps de réponse d'une application qui nécessite des connexions, c'est le cas notamment pour les applications Web. Lorsqu'un utilisateur envoie une demande sur le Web pour accéder à une ressource, cette dernière accède à une source de données. Etant donné que les utilisateurs se connectent à des applications sur Internet et s'en déconnectent souvent, les demandes de l'application pour l'accès aux données peut atteindre des volumes considérables. Par conséquent, la charge totale imposée au magasin de données devient vite élevée pour les applications Web et les performances se détériorent. Avec les fonctions de mise en pool des connexions, toutefois, les applications Web peuvent multiplier les performances par 20.
Avec la mise en pool des connexions, la plupart des demandes d'utilisateurs ne sollicitent pas de ressources système supplémentaires pour la création d'une connexion, car la source de données peut rechercher une connexion existante dans le pool de connexions et la réutiliser. Lorsque la demande est satisfaite et que la réponse a été renvoyée à l'utilisateur, la ressource rend la connexion au pool de connexions. Le surcoût lié à une déconnexion est évité. Chaque demande d'utilisateur génère une fraction du coût de connexion ou de déconnexion. Une fois les ressources d'origine utilisées pour générer des connexions dans le pool, la consommation de ressources supplémentaires est insignifiante, car les connexions existantes sont réutilisées.
Quand utiliser la mise en pool des connexions
Utilisez la fonction de mise en pool des connexions dans toute application qui répond à un ou plusieurs des critères suivants :
- L'application ne peut pas faire face au surcoût lié à l'obtention et à la libération de chaque connexion utilisée.
- L'application nécessite des transactions JTA (Java™ Transaction API) dans Application Server.
- L'application doit pouvoir partager les connexions entre plusieurs utilisateurs au sein de la même transaction.
- L'application doit tirer parti des fonctions du produit pour gérer les transactions locales dans le serveur d'applications.
- L'application ne gère pas la mise en pool de ses propres connexions.
- L'application ne gère pas les spécificités de création d'une connexion, telles que le nom de base de données, le nom d'utilisateur ou le mot de passe.

Comment les connexions sont mises en pool
Lorsque vous configurez une source de données ou une fabrique de connexions, vous devez lui attribuer un nom JNDI (Java Naming and Directory Interface) unique. Ce nom et les informations de configuration sont utilisées pour créer un pool de connexions. Un pool distinct est créé pour chaque source ou fabrique configurée.
Si vous exécutez un cluster de trois serveurs qui utilisent tous myDataSource et que le nombre maximal de connexions dans myDataSource est 10, vous pouvez générer jusqu'à 30 connexions (trois serveurs fois dix connexions).
Dans un cluster, trois contrôleurs z/OS contiennent chacun trois servants qui utilisent myDataSource, et en ce qui concerne le pool de connexions créé par le serveur d'applications pour chaque instance de myDataSource, vous devez régler le paramètre Nombre maximal de connexions sur 10. Vous pouvez donc générer jusqu'à 90 connexions (9 servants fois 10 connexions).
Pensez aux incidences potentielles de ce comportement sur le nombre de connexions pouvant être prises en charge par la ressource du système dorsal. Voir la rubrique relative aux paramètres de pool de connexions pour plus d'informations.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
- Chaque transaction de bean entity requiert une connexion supplémentaire à la base de données pour son traitement.
- Si des clones sont utilisés, il existe un pool de données par clone.
Sur les systèmes UNIX pris en charge, un processus DB2 distinct est créé pour chaque connexion ; ces processus affectent rapidement les performances sur les systèmes dont la quantité de mémoire est insuffisante et des erreurs sont générées.
N'oubliez pas non plus que vous ne pouvez partager que les connexions obtenues à partir d'un même pool.