Gestion des connexions SQL Server dans Tomcat 6

Question

Nous rencontrons des problèmes avec une application Web Java exécutée dans Tomcat 6 et utilisant JDBC pour se connecter à une base de données SQL Server.

Après quelques requêtes, le serveur d'applications est désactivé et les fichiers journaux contiennent des exceptions liées aux échecs de connexion à la base de données.

Nous n'utilisons aucun regroupement de connexions pour le moment et nous utilisons le pont de pilote JDBC / ODBC / ADO standard pour se connecter à SQL Server.

Devrions-nous envisager d'utiliser le regroupement de connexions pour éliminer le problème?

Aussi, devrions-nous changer notre pilote en quelque chose comme jTDS?

Answer 1

C’est le comportement correct si vous ne fermez pas vos connexions JDBC.

Une fois que vous avez fini de l'utiliser, vous devez appeler la méthode close () de chaque ressource JDBC et les autres ressources JDBC que vous avez obtenues avec elle.

Cela vaut pour Connection, Statement / PreparedStatement / CallableStatement, ResultSet, etc.

Si vous ne le faites pas, vous accumulez des ressources potentiellement énormes et probablement très limitées sur le serveur SQL, pour commencer.

Éventuellement, les connexions ne seront pas autorisées, les requêtes à exécuter et les résultats renvoyés échoueront ou se bloqueront.

Vous pourriez également remarquer que vos instructions INSERT / UPDATE / DELETE étaient suspendues si vous ne parveniez pas à commit () ou à rollback () à la conclusion de chaque transaction, si vous n'avez pas défini la propriété autoCommit sur true.

Ce que j'ai vu, c'est que si vous appliquez la rigueur mentionnée ci-dessus à votre code client JDBC, alors JDBC et votre serveur SQL fonctionneront à merveille. Si vous écrivez de la merde, alors tout se comportera comme de la merde.

De nombreuses personnes écrivent des appels JDBC dans l'attente de "quelque chose". sinon, relâchez chaque élément en appelant close () car c’est ennuyeux et que l’application et le serveur n’échouent pas immédiatement quand ils omettent de le faire.

Cela est vrai, mais ces programmeurs ont écrit leurs programmes pour jouer "99 bouteilles de bière sur le mur". avec leur (s) serveur (s).

Les ressources s'épuisent et les demandes entraînent généralement l'une ou plusieurs des conséquences suivantes: les demandes de connexion échouent immédiatement, les instructions SQL échouent immédiatement, se bloquent indéfiniment ou jusqu'à l'expiration d'un délai très long du délai de transaction très long, etc.,

.

Par conséquent, le moyen le plus rapide de résoudre ces types de problèmes SQL est de ne pas en vouloir au serveur SQL, au serveur d'applications, au conteneur Web, aux pilotes JDBC ou au manque décevant d'intelligence artificielle intégrée dans le récupérateur de déchets Java.

Le moyen le plus rapide de les résoudre consiste à filmer le type qui a écrit les appels JDBC dans votre application et qui parle à votre serveur SQL avec une fléchette Nerf. Quand il a dit, "Qu'est-ce que vous avez fait ça pour ...?!" Il suffit de pointer ce message et de lui dire de le lire. (Rappelez-vous de ne pas tirer pour les yeux, les objets entre les mains, des objets qui pourraient être dangereux / fragiles, etc.)

En ce qui concerne le regroupement de connexions qui résout vos problèmes ... non. Désolé, les pools de connexions accélèrent simplement l'appel pour obtenir une connexion dans votre application en lui attribuant une connexion préallouée, peut-être recyclée.

La fée des dents met de l’argent sous votre oreiller, le lapin de Pâques met des œufs & amp; des bonbons sous vos arbustes et le Père Noël met des cadeaux sous votre arbre. Mais, désolé de briser vos illusions, le serveur SQL et le pilote JDBC ne ferment pas tout parce que vous avez oublié. pour fermer tout ce que vous avez alloué.

Answer 2

Je voudrais certainement essayer jTDS. Je l'ai déjà utilisé avec Tomcat 5.5 sans aucun problème. Cela semble être un changement relativement rapide et à faible impact à effectuer comme étape de débogage. Je pense que vous le trouverez plus rapide et plus stable. Il a également l'avantage d'être open source.

À long terme, je pense que vous voudrez vous pencher sur la mise en commun des connexions pour des raisons de performances. Dans ce cas, je vous recommande de consulter c3p0 . Je pense que c'est plus flexible que les options de pooling intégrées pour Tomcat et je préfère généralement "sortir du conteneur". solutions pour que le remplacement des conteneurs soit moins douloureux à l’avenir.

Answer 3

C’est difficile à dire vraiment parce que vous avez fourni si peu d’informations sur l’échec réel:

  

Après quelques requêtes, l'application   serveur meurt et le dans les fichiers journaux   nous trouvons des exceptions liées à la base de données   échecs de connexion.

Pouvez-vous nous dire:

• exactement quelle est l'erreur vous voyez
• donnez-nous un petit exemple du code où vous connecter et entretenir l’un de vos demandes
• est-ce après une cohérence nombre de transactions qu'il échoue, ou est-ce apparemment aléatoire

J'ai écrit beaucoup de code java lié à la base de données (pratiquement tout mon code est lié à la base de données) et utilisé le pilote MS, le pilote jdt et celui de jnetDirect.

Je suis sûr que si vous nous fournissez plus de détails, nous pouvons vous aider.