Combien de connexions JDBC en Java?

Question

J'ai un programme Java composé d'environ 15 méthodes. Et, ces méthodes sont invoquées très fréquemment pendant l'exécution du programme. Pour le moment, je crée une nouvelle connexion dans chaque méthode et y invoque des instructions (la base de données est configurée sur une autre machine du réseau).

Ce que j'aimerais savoir, c'est: Devrais-je créer une seule connexion dans la méthode principale et le transmettre en tant qu'argument à toutes les méthodes nécessitant un objet de connexion, car cela réduirait considérablement le nombre d'objets de connexion dans le programme, au lieu de créer et de fermer des connexions très fréquemment dans chaque méthode.

J'imagine que je n'utilise pas les ressources de manière très efficace avec la conception actuelle et que de nombreuses améliorations sont possibles, étant donné que ce programme pourrait se développer considérablement à l'avenir.

Answer 1

Oui, vous devriez envisager de réutiliser les connexions plutôt que d'en créer de nouvelles à chaque fois. La procédure habituelle est la suivante:

• calculez le nombre de connexions simultanées que votre base de données peut gérer de manière judicieuse (par exemple, commencez avec 2 ou 3 par CPU sur la machine de base de données jusqu'à ce que vous découvriez que c'est trop peu ou trop - ça aura tendance à dépendre comment vos requêtes sont liées au disque)
• créez un pool de ce nombre de connexions: il s’agit essentiellement d’une classe à laquelle vous pouvez demander "la prochaine connexion libre". au début de chaque méthode, puis "repasser". à la piscine à la fin de chaque méthode
• votre méthode getFreeConnection () doit renvoyer une connexion libre, le cas échéant, sinon (1) créez-en une nouvelle, jusqu'au nombre maximal de connexions que vous avez décidé d'autoriser, ou (2) si le nombre maximal sont déjà créés, attendez qu’il devienne gratuit
• Je recommanderais à la classe Semaphore de gérer les connexions. J'ai en fait un court article sur mon site Web sur la gestion d'un pool de ressources avec un sémaphore avec un exemple, je pense que vous pourriez vous adapter à votre objectif

Quelques considérations pratiques:

• Pour obtenir des performances optimales, vous devez faire attention à ne pas "cochon". une connexion alors que vous ne l'utilisez pas réellement pour exécuter une requête . Si vous établissez une connexion du pool une fois, puis que vous la transmettez à diverses méthodes, vous devez vous assurer que vous ne le faites pas accidentellement.
• N'oubliez pas de renvoyer vos contacts à la piscine! (essayez / enfin est votre ami ici ...)
• Sur de nombreux systèmes, vous ne pouvez pas garder les connexions ouvertes "pour toujours" : le système d'exploitation les fermera au bout d'un certain temps. Ainsi, dans votre méthode de "renvoi d'une connexion au pool", vous devez penser aux connexions "abandonnées" qui existent depuis longtemps (intégrez un mécanisme de mémorisation, par exemple: un objet encapsuleur autour d'un objet de connexion JDBC que vous pouvez utiliser pour stocker des mesures telles que celle-ci)
• Vous pouvez envisager d'utiliser des instructions préparées.
• Au fil du temps, vous devrez probablement modifier la taille du pool de connexions
.

Answer 2

Vous pouvez passer la connexion ou, mieux, utiliser quelque chose comme le regroupement de bases de données Jakarta. http://commons.apache.org/dbcp/

Answer 3

Vous devez utiliser un pool de connexions pour cela.

De cette façon, vous pourrez demander la connexion et la relâcher lorsque vous en aurez fini et la renvoyer dans le pool

.

Si un autre thread souhaite une nouvelle connexion et que celle-ci est en cours d'utilisation, une nouvelle connexion peut être créée. Si aucun autre thread n'utilise une connexion, celle-ci pourrait être réutilisée.

De cette façon, vous pouvez laisser votre application telle quelle (et ne pas transmettre la connexion de part en part) tout en utilisant les ressources correctement.

Malheureusement, les ConnectionPools de première classe ne sont pas très faciles à utiliser dans les applications autonomes (ce sont les serveurs d'applications par défaut). Un microconteneur (tel que Sping) ou un bon framework (tel que Hibernate) pourrait probablement vous permettre de l'utiliser.

Cependant, ils ne sont pas trop difficiles à coder à partir de zéro.

:)

Cette recherche google vous aidera vous en apprendrez plus sur la façon d’en utiliser un.

Parcourez

Answer 4

De nombreux pilotes JDBC effectuent le regroupement de connexions pour vous. Il est donc peu avantageux de procéder à un regroupement supplémentaire dans ce cas. Je vous suggère de consulter la documentation de votre pilote JDBC.

Une autre approche des pools de connexions consiste à

• Établissez une connexion pour tous les accès à la base de données avec un accès synchronisé. Cela ne permet pas la concurrence mais est très simple.
• Stocker les connexions dans une variable ThreadLocal (override initialValue ()) Ceci fonctionne bien s'il existe un petit nombre fixe de threads.

Sinon, je suggérerais d'utiliser un pool de connexions.

Answer 5

Si votre application utilise un seul thread ou effectue toutes ses opérations de base de données à partir d'un seul thread, vous pouvez utiliser une seule connexion. En supposant que vous n’ayez pas besoin de plusieurs connexions pour une autre raison, ce serait de loin l’implémentation la plus simple.

En fonction de votre pilote, il peut également être envisageable de partager une connexion entre les threads. Ce serait également correct si vous ne vouliez pas que le pilote mente sur la sécurité de ses threads. Consultez la documentation de votre pilote pour plus d'informations.

En règle générale, les objets ci-dessous " Connexion " ne peut pas être utilisé en toute sécurité à partir de plusieurs threads; il est donc généralement déconseillé de partager les objets ResultSet, Statement, etc. entre les threads - de loin la meilleure politique consiste à les utiliser dans le même thread qui les a créés; c'est normalement facile, car ces objets ne sont généralement pas conservés trop longtemps.