Commençons par comprendre les propriétés mysql.
interactive_timeout:délai d'attente interactif pour les sessions du shell mysql en quelques secondes comme mysqldump ou les outils de ligne de commande mysql. les connexions sont en état de veille. La plupart du temps, cette valeur est définie sur une valeur plus élevée car vous ne voulez pas qu'elle soit déconnectée pendant que vous faites quelque chose sur mysql cli.wait_timeout:le nombre de secondes pendant l'inactivité que MySQL attendra avant de fermer une connexion sur une connexion non interactive en secondes. exemple :connecté depuis java. les connexions sont en état de veille.
Maintenant, comprenons les propriétés c3po et sa relation avec les accessoires DB. (Je vais juste copier de votre question)
Il s'agit de la durée pendant laquelle un objet de connexion peut être utilisable et sera disponible dans le pool. Une fois le délai d'expiration dépassé, c3po le détruira ou le recyclera.
Maintenant, le problème survient lorsque vous avez maxIdleTime supérieur au wait_timeout .disons si le mxIdleTime : 50 secondes et wait_timeout : 40 s alors il y a une chance que vous obteniez Connection time out exception: Broken Pipe si vous essayez de faire une opération dans les 10 dernières secondes. Donc maxIdelTime doit toujours être inférieur à wait_timeout .
Au lieu de maxIdleTime, vous pouvez utiliser les propriétés suivantes.
idleConnectionTestPerioddéfinit une limite de temps pendant laquelle une connexion restera inactive avant de la tester. SanspreferredTestQuery, la valeur par défaut estDatabaseMetaData.getTables()- qui est indépendant de la base de données, et bien qu'il s'agisse d'un appel relativement coûteux, il convient probablement à une base de données relativement petite. Si vous êtes paranoïaque à propos des performances, utilisez une requête spécifique à votre base de données(i.e. preferredTestQuery="SELECT 1")maxIdleTimeExcessConnectionsramènera le connectionCount à minPoolSize après un pic d'activité.
Veuillez noter que toutes les propriétés du pool (par exemple, maxIdleTime ) n'affecte que les connexions qui sont dans le pool c'est-à-dire que si hibernate a acquis une connexion et la maintient inactive pendant plus de maxIdleTime et essaie ensuite d'effectuer n'importe quelle opération, vous obtiendrez "Broken Pipe"
Il est bon d'avoir moins de wait_timeout sur mysql mais ce n'est pas toujours correct quand vous avez une application déjà construite. Vous devez vous assurer avant de la réduire que dans votre application vous ne gardez pas la connexion ouverte pendant plus de wait_time sortie.
Vous devez également considérer que l'acquisition d'une connexion est une tâche coûteuse et si le temps d'attente est trop court, cela va à l'encontre de l'objectif d'avoir un pool de connexions, car il essaiera fréquemment d'acquérir des connexions.
Ceci est particulièrement important lorsque vous ne gérez pas les connexions manuellement, par exemple lorsque vous utilisez l'API transnationale Spring. Spring démarre la transaction lorsque vous entrez un @Transaction méthode annotée afin qu'elle acquière une connexion à partir du pool. Si vous effectuez un appel de service Web ou lisez un fichier qui prendra plus de temps que wait_time out, vous obtiendrez une exception.
J'ai rencontré ce problème une fois.
Dans l'un de mes projets, j'avais un cron qui s'occupait du traitement des commandes des clients. Pour le rendre plus rapide, j'ai utilisé le traitement par lots. Maintenant, une fois que je récupère un lot de clients et que je fais un traitement (pas d'appels à la base de données). Lorsque j'essaie d'enregistrer toutes les commandes que j'ai utilisées pour obtenir une exception de tuyau cassé. Le problème était que mon délai d'attente était de 1 minute et que le traitement des commandes prenait plus de temps que cela. Nous avons donc dû l'augmenter à 2 minutes. J'aurais pu réduire la taille du lot, mais cela ralentissait le traitement global.
