Dans mon application Web, je fais une utilisation intensive d'une base de données.
J'ai un servlet abstrait, à partir de laquelle tous les servlets nécessitant une connexion de base de données, héritent. Ce servlet Abstract crée une connexion de base de données, appelle la méthode abstraite qui doit être remplacée par les servlets héritables pour faire leur logique, puis ferme la connexion. Je n'utilise pas la mise en commun de la connexion, car ma candidature aura un nombre très limité d'utilisateurs et d'opérations.
Ma question est, quel est le pire qui peut se produire si je ne ferme jamais le Resultats S, Paretstatement s et instruction s que mes servlets héritantes créent, si la connexion s qui les crée est toujours fermée?
5 Réponses :
AFAIK, vous finirez par faire de l'épuisement des ressources de votre serveur de base de données en raison des poignées de fichier liées, des ressources nécessaires à la contenant le jeu de résultats associé à une instruction donnée, etc. Il peut y avoir des implémentations de pilote / de base de données intelligentes qui s'assurent bien Que dès que la connexion est fermée, toutes les ressources associées sont libérées, mais cela ne fait que partie de la spécification pourrait éventuellement venir vous mordre à long terme. Toute raison pour laquelle vos classes primordiales ne peuvent pas fermer les ensembles de résultats et les déclarations qu'ils utilisent?
> Toute raison pour laquelle vos classes de dépassement ne peuvent pas fermer les ensembles de résultats et les déclarations qu'ils utilisent? - Aucune raison particulière, sauf que j'oublie souvent d'écrire ce Rs.close () chose, et de plus, vous devez les placer dans la clause enfin , puisque les opérations de DB Sqlexceptions, et c'est un peu lourd.
Malheureusement, ce n'est pas une raison forte de renoncer à nettoyer les ressources. Si vous recherchez une fermeture de vos ressources DB de manière propre, examinez les dbutils ( Commons.apache.org/ DButils ) projet. Si vous n'êtes pas à l'aise avec la prise en charge de l'ensemble du pot, vous pouvez simplement attraper le code source de la classe DButils qui est responsable du nettoyage des ressources et vous devriez être bon à partir.
Merci pour le lien, je vais lui donner un coup d'oeil.
En passant, en ce qui concerne la fermeture des connexions discrètement, Java7 est la réponse avec sa nouvelle Syntaxe
Je crois que le commentaire d'Ibolit ci-dessus signifiait dire la nouvelle déclaration «essai-with-woo-ressources» de Java. Voir le tutoriel: docs.oracle.com/javase/tatuutorial/essential/ Exceptions / ...
Je suis sûr que la fermeture de la connexion fermera les instructions associées, les résultats dans les résultats et d'autres objets associés. Cependant, tout cela consommera des ressources sur le client et peut être sur le serveur de base de données jusqu'à la fermeture de la connexion.
Si dans votre cas, vous savez que vous fermerez la connexion très bientôt vous ne risquez probablement pas beaucoup bien que je ne pense pas que cela soit considéré comme une meilleure pratique.
Cependant, cela n'est valable que dans votre réglage actuel. Bien que vous ne vouliez pas utiliser la mise en commun de la connexion, je pense que c'est une mauvaise idée même avec peu d'utilisateurs / opérations, car l'ouverture d'une connexion de base de données n'est pas bon marché. Donc, même dans votre pool de connexions de contexte, vous aider à obtenir votre système plus réactif.
Juste une note sur la collecte des ordures. Avant de fermer la connexion, les déclarations inutilisées ou les résultats peuvent être gisés. mais Lorsqu'il s'agit de libérer des ressources système telles que des fichiers ou des ressources plus généralement non Java (telles que les curseurs sur un serveur de base de données), le JVM GC ne doit pas être invoqué. Par exemple, si votre demande client ouvre beaucoup de résultatssets mais n'utilisez qu'une petite fraction de la mémoire de tas allouée, le GC ne frappe jamais pendant que le serveur de base de données est étouffé par les curseurs ouverts. Si Lorsque votre candidature changera, vous pouvez faire face à des problèmes car vous n'avez pas fermé vos déclarations et résultats.
Eh bien, la création de piscines est également en cours et, lorsque vous n'avez que 5 utilisateurs (c'est une chose d'entreprise), et ils font environ 1-2 opérations une heure, la mise en commun peut ralentir des choses, comme il essaiera de chercher des connexions de travail. Et puis essayez de créer de nouveaux, car les anciens auront "morts". Et j'essaie aussi d'éviter une "optimisation prématurée" :)
@lbolit - Vous ne créez que la piscine une fois, au démarrage. Sinon, vous devez renégocier une connexion sur chaque demande. Les frais généraux d'une recherche d'une piscine sont minuscules par rapport aux frais généraux de créer une demande. Si vous utilisez une piscine maintenant, vous n'aurez pas à le réparer lorsque l'utilisation de l'application change.
@Lbolit Vous avez raison dans votre cas Il n'y a certainement pas de précipitation pour mettre en œuvre la piscine de connexion.
@ORANGEDOG - Autant que je sache, les connexions dans la piscine expirent après avoir été inactive pendant une certaine période, puis ils doivent être créés à nouveau, ce qui conduit à la même générale que lors de la création de connexions "à partir de zéro". Mais cela fait longtemps que j'ai utilisé un pool de connexion, donc je me trompe.
@Lbolit - Correct, mais "une période de temps" peut généralement être ce que vous voulez. Si les demandes sont que peu fréquentes, vous ne devriez probablement pas vous soucier de la surcharge de connexion, mais les connexions en commun sont plus faciles à gérer et aideront lorsque les exigences changent.
Une connexion à la base de données n'est pas la seule chose que votre application s'attaque. Il y a d'autres ressources en jeu.
Ils seront libérés à un moment donné, si vous ne les libérez pas vous-même, mais si vous pouvez le faire, vous devriez.
En outre, en cas de mise en commun de la connexion lorsque vous appelez Connection.close (), la connexion sera renvoyée à la piscine et non fermée. Donc, il ne faut donc pas compter sur cette connexion.FLOSE () fermera également les déclarations - il est recommandé de toujours fermer les déclarations explicitement.
C'est un peu d'API de Crap - finit avec vous, vous écrivez une charge de code de plaque de la chaudière.
Je pense que la meilleure façon d'aller est envelopper les classes et le faire pour que la connexion dispose de la connexion (comme Vous pouvez suivre ce qui est fait sur le chemin des appels emballés).
Tant que vous avez un IDE qui peut vous générer des méthodes de délégation dans une classe, c'est un travail trivial pour envelopper des trucs comme ceci.
Je n'ai pas réalisé que toutes les choses supplémentaires nécessaires à disposer, mais je viens de repérer quelqu'un le faire ici, cependant j'ai de la chance car nous envisageons déjà les classes de base pour transformer toutes les exceptions ennuyeuses en runtimédies et de fournir quelques opérations SQL de niveau de haut niveau.
J'ai fait une petite classe pour suivre les différents bits de choses: puis par exemple dans Connexion emballée (qui est quelque chose qui enveloppe une connexion de base de données): Vous pouvez ensuite transmettre la même liste dans des versions enveloppées de jeux de préparé / résultats (ce que je n'ai pasmontré ici) et etc. et l'utiliser de la même manière. Je ne sais pas ce que les autres utilisent, mais dans une idée, vous pouvez activer un avertissement pour des éléments automatiques qui ne sont pas en utilisant (ou devrais-je dire essai avec ressources) Bloc: Celles-ci utilisent des blocs Vous essayez enfin de fermer automatiquement et ne peut être utilisé que avec des objets du type d'interface AutoClosable Je ne sais pas pourquoi cet avertissement n'est pas allumé par défaut dans l'idée, mais vous y allez.