mon intention est de fermer toutes les ressources DB une fois que l'utilisateur se déconnecte
déjà un signe d'une mauvaise pratique. Les ressources DB doivent être acquises et fermées dans la portée la plus courte possible, c'est-à-dire dans le même bloc de méthode. Vous ne pouvez jamais obtenir une ressource DB (Connection, Statement et/ou ResultSet) en tant que variable statique ou instance. C'est la réception des fuites de ressources et des problèmes plus graves. Si l'intention initiale était d'améliorer les performances de connexion, vous devez introduire un pool de connexions. Gardez à l'esprit que ce n'est pas une excuse pour garder les connexions ouvertes vous-même. Il suffit de les acquérir et de les fermer dès que possible de la même manière, l'implémentation du pool de connexion elle-même s'inquiète de la fermeture de la connexion ou de la relâcher dans le pool. Tout est entièrement transparent. Les serveurs d'applications décents sont livrés avec des fonctionnalités de pool de connexions dans les sources de données JNDI. Fais-en usage. Une fois cela fait, vous n'avez pas besoin de vous soucier des ressources DB ouvertes ni des performances du tout.
Je ferme les ressources DB dans le même bloc que celui où j'ouvre et j'utilise la mise en commun des connexions Weblogic. Mon vrai problème est que certaines requêtes prennent beaucoup de temps à s'exécuter et une fois que l'utilisateur se déconnecte, il est possible que ces requêtes soient toujours en cours d'exécution et consomment des ressources système. Je cherche un moyen de mettre fin à ces connexions après que l'utilisateur se déconnecte. –
Stockez un handle dans la portée de session et utilisez 'HttpSessionListener # sessionDestroyed()' pour les récupérer et les arrêter tous. – BalusC