12
votes

Quelle méthode peut être utilisée pour l'enquête sur l'utilisation de la connexion de base de données en Java?

Quelle méthode peut être utilisée pour l'enquête sur l'utilisation de la connexion de base de données en Java?

Un développeur prend en charge un programme Java complexe qui est en train d'épuiser le nombre de connexions de base de données disponibles. Depuis que le problème est sporadique, il serait utile de savoir quel thread a ouvert plusieurs connexions à la base de données pour concentrer les efforts dans cette zone.

En fin de compte, le correctif correct semble être de réécrire le programme de réutiliser les connexions et non d'ouvrir plusieurs connexions par fil.

Je demande, quelles méthodes le développeur doit-elle avoir dans sa boîte à outils pour pouvoir enquêter sur les ressources I.E. Les connexions de base de données attribuées par un thread.


0 commentaires

5 Réponses :


7
votes

regarder log4jdbc . Il vous permet d'examiner tous les trucs sur votre JDBC, notamment des connexions d'ouverture / fermeture ainsi que des informations de numéro de connexion.


0 commentaires

1
votes

Les pools de connexion peuvent vous donner des diagnostics. Par exemple, Consultez la propriété de débogUneReTurnedConnectionSACKTraces pour le pool de connexion C3P0:

http://www.mchange.com/projects/c3p0/index .html # DebugUneReturnedConnectionStackTraces


0 commentaires

4
votes

Quelqu'un m'a montré ConnleakFinder Récemment, "Un outil simple pour identifier les fuites de connexion JDBC dans le code Java". Je ne l'ai pas testé moi-même jusqu'à présent, mais cela devrait vous permettre de voir qui n'a pas fermé la connexion après utilisation . Voir Connexion + fuite + comment + à + recherche.htm .

Mais en effet, vous devriez en effet, vous devez utiliser un pool de connexion (par exemple C3P0 ).


0 commentaires

0
votes

P6SPY est un cadre open source pour prendre en charge les applications interceptées et modifier éventuellement modifier les relevés de base de données.

de http://www.p6spy.com/about.html
La distribution P6SPY comprend les modules suivants:

  • p6log. P6LOG intercepte et enregistre les instructions de la base de données de toute application utilisant JDBC. Cette application est particulièrement utile pour les développeurs de surveiller les instructions SQL produites par les serveurs EJB, permettant au développeur d'écrire du code qui permet d'obtenir une efficacité maximale sur le serveur. P6SPY est conçu pour être installé en minutes et ne nécessite aucun changement de code.
  • p6outage. P6outage détecte des énoncés de longue date pouvant indiquer un fonctionnement d'une panne de base de données et enregistrera toute déclaration qui dépasse la limite de temps configurable lors de son exécution. P6OUTAGE a été conçu pour minimiser toute pénalité de performance d'exploitation forestière en enregistrant uniquement des relevés longs en cours d'exécution.

1 commentaires

Alors que P6SPY est un outil agréable, je ne vois pas comment cela vous aide à rechercher des problèmes de chasse.



4
votes

Pas un outil spécifique, mais plutôt une technique de débogage pour suivre le code du code responsable des connexions ouvertes ou d'autres ressources.

Je suppose que vous utilisez une méthode cohérente du côté Java pour obtenir une connexion DB (mise en commun ou non).

L'idée est de créer une classe d'emballage très légère autour de votre usine de connexion / piscine ou quoi que ce soit. Le wrapper mettra en œuvre n'importe quelle interface JDBC de sens afin que vous puissiez l'échanger pour votre objet de connexion normal, mais la plupart des méthodes appellent / retourneront de manière transparente la connexion sous-jacente.

Si vous utilisez une sorte de cadre IOC (E.G. Spring), vous devriez être capable d'échanger facilement la classe de connexion / usine à un niveau de configuration. Maintenant, tout votre code Java utilisera votre nouveau wrapper de connexion DB.

Si vous utilisez une piscine, appelez Connection.Close () Retourne généralement l'objet à la piscine au lieu de détruire la connexion. Donc, cette technique fonctionne pour une fuite de connexion normale ou vient de «non renoncée à la piscine (piscine épuisée)» Fuite.

Maintenant, nous devons simplement enregistrer les bits intéressants et définir un piège pour les connexions fuites.

Trac de pile pour identifier le créateur

Dans le constructeur ou la méthode d'usine de votre emballage de connexion Créez un nouvel objet loveable et stockez-le comme une variable locale dans votre enveloppe pour plus tard. Nous utilisons un jetable car il est plus rapide / moins cher que d'utiliser thread.CurrentThread (). GetStackTrace () . .

Définir le "piège"

Implémentez la méthode finaliser dans votre classe wrapper. Ceci est une méthode de nettoyage appelée par la GC lorsque l'objet est en train d'être détruit car il n'est plus utilisé.

Le finaliser la méthode doit vérifier "suis-je fermé?". Si déjà fermé, tout va bien ... Toutefois, si la connexion est en train d'être gérée et qu'elle n'a pas été fermée ... alors il s'agit d'une connexion "fuite".

MAINTENANT Le DANSABLE revient dans la lecture. Nous pouvons saisir le lancer et sortir un joli journal de journal indiquant quelque chose comme: "Je suis une connexion fuite et voici une trace de pile impliquant mon créateur."

Développer l'idée

Cette méthode peut être adaptée à une variété de situations. Vous pouvez bien sûr conserver d'autres types de données dans votre wrapper pour dépanner votre problème spécifique. Par exemple la création. Ensuite, vous pouvez sonder les connexions à long terme et impliquer à nouveau le Créateur. Ou vous pouvez sonder des connexions existantes et analyser les traces de pile loveable pour obtenir des données sur quel code utilise le nombre de connexions au fil du temps.

Il y a probablement un outil hors tension pouvant également faire ce type de choses, mais la quantité de code requise pour appliquer cette technique est très minime dans la plupart des cas (en supposant que vous ayez un moyen facile d'échanger votre dB. Connexion usine sans recherche-remplacement de votre code global).


2 commentaires

La méthode que vous souhaitez implémenter s'appelle finaliser non enfin .


Merci @Ring. Fixé. Été plus de 7 ans depuis mes jours Java. Appréciez l'aide.