pool de connexion c3p0 sans test de chaque check-in ou check-out

Question

De l'c3p0 documentation:

Pour certaines applications, la haute performance est plus important que le risque d'une exception de base de données occasionnelle. Dans sa configuration par défaut, c3p0 ne fait aucun test de connexion. Réglage d'un assez long idleConnectionTestPeriod, et ne pas tester sur la caisse et check-in du tout est une excellente approche, haute performance.

Si je comprends la signification des propriétés de configuration c3p0 correctement, si la base de données devient indisponible pour une courte période de temps et récupère ensuite (par exemple, il est redémarré ou un problème de réseau apparaît), et s'il y a une assez Une utilisation élevée des connexions qui sont regroupées dans le c3p0 de sorte qu'aucune connexion est inactive plus longtemps que idleConnectionTestPeriod, alors aucune de ces connexions ne serait jamais testée pour la validité et toutes les tentatives pour les utiliser seraient infructueuses. Fondamentalement, le pool de connexion ne récupèrerait pas automatiquement de l'indisponibilité db.

Est-il juste mauvais libellé dans la documentation indiquant que ce est une excellente approche de haute performance sans avertissement que le pool de connexion perd la capacité d'auto-récupérer des connexions non valides ou j'ai mal compris le sens de les propriétés de configuration pertinentes?

Answer 1

Huh. J'ai écrit cela, probablement il y a plus de dix ans, et vous avez raison, ce n'est pas un bon conseil. A l'origine, le test de connexion dans c3p0 était souvent très coûteux (parce que pour l'indépendance de dbms/driver et la certitude d'un test de validité complet, il utilisait un test coûteux de métadonnées getTables (...)), et je conseillais fortement aux gens de tester asynchronously , dans les vérifications et les essais au ralenti. Une fois que preferredTestQuery puis jdbc4 Connection.isValid() a rendu possible des tests fiables et efficaces, j'ai révisé les docs pour supprimer le découragement des contrôles synchrones. Mais apparemment, cela est resté, et c'est un mauvais conseil même pour les vieux jours. En pratique, si vous ne testez pas pendant la vérification, je recommande des tests asynchrones sur checkin et tests inactif, et des tests d'inactivité modérément fréquents (30 secondes-ish) généralement, pour réduire la probabilité qu'une application voit des connexions périmées et le délai avant Les connexions sont rafraîchies après une panne.

Je vais réviser cela pour l'avenir. Merci pour la capture.