Il n'existe pas d'annulation de connexion. Peut-être que vous vouliez dire une annulation de transaction. Vous ne devez jamais revenir en arrière sauf si vous avez l'intention de perdre les modifications apportées à la base de données dans la transaction, et vous ne devez jamais valider à moins d'avoir l'intention de valider toutes les modifications apportées à la transaction. Cela dit, je ne comprends pas le terme «nous faisons d'abord une annulation de connexion préemptive pour éviter les exceptions de connexion» et pourquoi vous le feriez en premier lieu. En supposant que vous faites référence à l'invocation de la méthode Connection.rollback(), je considère que c'est une mauvaise pratique. Cela entraînerait une perte de performance, car il nécessite un appel réseau, et oblige la base de données à rejeter l'état de la transaction associée (ce qui n'a aucun sens dans ce scénario, car aucun travail n'a encore été fait). Si vous souhaitez éviter les exceptions impliquant une connexion morte extraite d'un pool de connexions, vous devez configurer le pool pour vérifier si la connexion n'est pas périmée (généralement en exécutant une instruction SQL de test) avant de renvoyer la connexion à l'application. Une fois que l'application a acquis la connexion, elle ne doit pas conserver la connexion après qu'elle n'en a plus besoin; l'application devrait idéalement retourner la connexion à la piscine. Si vous observez la présence de l'objet de connexion, la connexion physique sous-jacente n'est pas disponible pour d'autres demandes et peut en fait être fermée par un pare-feu configuré pour fermer les connexions actives au-delà d'une certaine durée.