Un pool est un ensemble d'objets réutilisables. Il permet de partager des objets déjà crées entre plusieurs requêtes de manière à éviter les coûts liés à de nouvelles instanciations. Dans les applications J2EE on retrouve les pools à plusieurs niveaux :

Au niveau des servlets : une servlet associe un thread à chaque requête nouvellement reçue mais cela ne veut pas dire qu’elle crée autant de threads qu’il y a de requêtes entrantes. Pour ne pas épuiser les ressources du serveur, le conteneur crée un nombre limité de threads et les place dans un pool. Parce que le nombre des requêtes entrantes est largement supérieur à celui des threads placés dans le pool, il doit mettre les requêtes excédentaires dans une file d’attente jusqu'à ce qu’un nouveau thread soit libéré. A l’issue du traitement d’une requête le thread qui lui a été assigné n’est pas détruit. Il est gardé dans le pool et réinitialisé pour qu’une nouvelle requête puisse s’en servir.
 

Figure 37: Pool de threads maintenu par un serveur d’application [177]

Au niveau des bases de données : la connexion à une base de données est une opération très coûteuse en mémoire et en processeur. A l’instar des threads un développeur ne peut pas se permettre de créer autant de connexions qu’il y a de requêtes entrantes. De la même manière, il ne peut pas partager une seule connexion entre toutes les requêtes au risque de condamner les traitements parallèles et les accès concurrentiels à la base de données.  Comme le montre le diagramme de classe de la figure 38 le ConnectionPool regroupe un nombre limité de connexions déjà créées (ConnectionImpl). Lorsqu’une nouvelle requête arrive le ConnectionPool appelle la méthode acquireImpl() qui lui retourne une connexion prête à l’emploi. Une fois le traitement de la requête terminé le ConnectionPool appelle la méthode releaseImpl() pour libérer la connexion et permettre à de nouvelles requêtes de la réutiliser.

Figure 38: Diagramme de classe du ConnectionPool [178]

Au niveau de la couche métier : à la différence des stateful session beans, les stateless session beans ne conservent pas de données personnalisées dans les objets de session. Cette propriété facilite énormément leur conservation dans des pools. Lorsque le conteneur d’EJB reçoit une requête, il n’a pas à se soucier des données personnalisées du client qui l’a envoyée. Parce qu’elles sont identiques, il peut lui retourner n’importe quelle instance de l’EJB pool. Ce raisonnement s’applique par transitivité aux entity beans et aux message driven beans mais pas aux stateful session beans parce qu’ils conservent pendant la session les données personnalisées de chaque client. En fait, sans réinitialisation, une réutilisation des stateful session beans peut affecter la confidentialité et l’intégrité des données (par exemple si un client réutilise le panier d’achat rempli par autre client).

Cela dit il n’y a pas de restrictions quant aux types d’objets qu’on peut placer dans un pool. La reutilisabilité est pratiquement la seule condition qu’ils doivent vérifier. Comme le montre la figure 39 un resource pool peut être par abstraction généralisé à tous les types d’objets via une classe intermédiaire (Factory) qui permet la factorisation des méthodes et des propriétés du pool.

Figure 39: Factorisation des ressources d’un pool [179]

La méthode createResource() de la classe Factory permet de créer une nouvelle instance de l’objet qu’on souhaite placer dans le pool. Avant de pouvoir réutiliser cette instance le pool doit appeler la méthode validateResource( ) pour la réinitialiser.

Notes de bas de page

[177] Source : Adaptation d’une figure publiée dans: Threading/queuing "funnel." From IBM Software Group Services Performance Workshop presented by Stacy Joines, 2001, Hursley, U.K. © IBM Corp. 2001

[178]  Adaptation d’un diagramme de classe publié à l’adresse: http://www.developer.com/java/other/article.php/626291 , Wiebe de Jong, Implement a JDBC Connection Pool via the Object Pool Pattern

[179] Source: William Crawford, Jonathan Kaplan, J2EE Design Patterns, O'Reilly, September 2003, ISBN: 0-596-00427-3, 368