Temporisations MySQL pendant la validation

Question

Nous rencontrons des problèmes de réseau mystérieux avec MySQL. La requête de mise à jour simple (mise à jour d'une seule ligne à l'aide de l'index) s'exécute généralement immédiatement, puis parfois (disons 1 à 1000 fois) échoue avec timeout. Idem avec une simple requête d'insertion. La base de données n'est pas surchargée. Nous soupçonnons des problèmes de réseau et sommes à la recherche de solutions, donc si quelqu'un a eu ce genre de problèmes, je voudrais vraiment me diriger à ce sujet.

Maintenant au point principal. Pour aggraver les choses, insérer la requête échoue lors de la validation de la transaction (nous avons peu de requêtes similaires, mais cela se produit même dans le plus simple - juste insérer seul dans une seule table, pas de verrous, rien). Lorsque cela se produit, transaction.Commit renvoie Exception. Nous l'attrapons et supposons que la transaction a été annulée et que nous réessayons d'insérer à nouveau des données.

Le résultat est deux lignes avec les mêmes données dans la table. Quelles hypothèses sont possibles si la validation échoue? La rangée a-t-elle été insérée ou non Ce comportement est-il bug dans MySql Connector/Net ou est-ce par conception? Un conseil (à côté de vérifier manuellement si les données sont dans la table ou non)?

Merci d'avance. Branko

p.s. J'ai posté ce même message sur le forum MySQL .NET. Je m'excuse si cela dérange quelqu'un, mais je deviens désespérée. O :-)

Answer 1

Si la validation échoue avec une erreur de réseau, aucune hypothèse n'est possible. Je comprends qu'il est difficile de programmer contre cela, mais c'est le cas;) L'augmentation du délai de commande pourrait aider quelque peu ici. Mais encore une fois, si la connexion est perdue après que les changements de transaction ont été rendus persistants dans la base de données, mais que le client n'a pas reçu d'accusé de réception du serveur, l'état de la transaction n'est pas défini.