Notez que j'ai longtemps été accro à MySQL à cause d'une erreur.
Si vous exécutez SQL deux fois de suite com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure Une erreur se produit et une table vide est renvoyée. Immédiatement après le premier problème, la redirection est passée à une autre page et, lorsque le SQL suivant y a été émis, une erreur s'est produite. Cependant, immédiatement après cela, si vous actualisez manuellement la page à l'aide du navigateur avec la même URL, le tableau correct sera affiché.
J'ai été chargé comme tâche d'apprentissage et j'ai créé un CRUD HP. Lorsque j'utilisais h2database de la base de données en mémoire sur le serveur local intégré IDE par STS (kit Eclipse + Spring), On m'a dit de changer la base de données en MySQL et de l'exécuter en mode serveur. Par conséquent, j'ai construit un environnement CentOS + MySQL en utilisant Vagrant en référence à l'installation de points et je l'ai reconnecté. Ensuite, la base de données qui fonctionnait normalement avant le changement a cessé de fonctionner à certains endroits. L'un d'eux est le symptôme ci-dessus.
Même si la fermeture () de la première connexion à la base de données n'était pas terminée, j'ai essayé de me connecter en plus et j'ai dépassé le nombre de connectables, ou le traitement SQL n'a pas pu rattraper et il y a eu un conflit. Actuellement, la connexion à la base de données et l'émission SQL sont effectuées en tant qu'ensemble, de sorte que l'on ne sait pas encore à quel point elle s'est arrêtée.
Avant le premier problème SQL + sshConnection close et le deuxième problème SQL
try {
Thread.sleep(3000);//if here is not this,caused MySQL error.communication link failer.
}catch(InterruptedException e) {e.printStackTrace();}
Je l'ai mis et cela a fonctionné pour le moment.
Il existe une grande différence de vitesse de réponse entre la base de données intégrée en mémoire et le serveur virtuel. Comme les deux sont dans le même PC, il ne devrait y avoir aucune différence de vitesse de réponse, mais osez-vous simuler le temps nécessaire à la communication afin de produire des problèmes qui peuvent survenir sur le serveur de production?
À l'origine, ce n'est pas le support ci-dessus, et ce n'est peut-être pas une solution fondamentale à moins que vous ne changiez les paramètres de l'environnement MySQL, comme l'augmentation du nombre de connectables. Si vous connaissez la bonne solution, nous apprécions vos commentaires.