A quoi sert Connection.isClosed() de JDBC, et pourquoi Snaq DBPool se comporte-t-il mal?

Question

J'ai le code suivant en Java:

if(!conn.isClosed()) 
{ 
    conn.close(); 
} 

lieu de travail, je suis récompensé par:

java.sql.SQLException: Connexion déjà fermé

Mon objet de connexion est un Snaq. db.CacheConnection

J'ai vérifié les JavaDocs pour isClosed, et ils déclarent que:

Cette méthode ne peut généralement pas être appelée pour déterminer si une connexion à une base de données est valide ou non valide. Un client typique peut déterminer qu'une connexion est invalide en attrapant toutes les exceptions qui pourraient être levées lorsque une opération est tentée.

Mes questions sont les suivantes:

1) Qu'est-ce que le bien est isClosed JDBC() de toute façon? Depuis quand utilisons-nous Exceptions en Java pour vérifier la validité?

2) Quel est le modèle correct pour fermer une base de données? Devrais-je simplement fermer et avaler des exceptions?

3) Toute idée pourquoi SnaqDB fermera la connexion? (Mon back-end est un Postgres 8.3)

Answer 1

Je vais répondre à vos questions avec les numéros correspondants:

1. Je suis d'accord avec vous, il semble étrange que isClosed fournit l'état fermé uniquement sur une base meilleur effort, et que votre code doit encore être préparé pour attraper l'exception lors de la fermeture de la connexion. Je pense que la raison est que la connexion peut être fermée à tout moment par la base de données, donc tout état renvoyé par une méthode d'état de requête comme isClosed est intrinsèquement obsolète - l'état peut changer entre la vérification isClosed et l'appel close sur le Connection. Appeler close n'a aucun effet sur vos données et sur les requêtes précédentes. Les opérations JDBC s'exécutent avec des résultats synchrones, de sorte que toute exécution utile a réussi ou échoué au moment où isClosed est appelé. (Vrai avec les limites de transaction automatique ou explicite.) Si votre application est un utilisateur unique accédant à une base de données locale, l'affichage de l'erreur à l'utilisateur peut éventuellement aider à diagnostiquer les problèmes. Dans d'autres environnements, consigner l'exception et l'avaler est probablement le meilleur plan d'action. D'une manière ou d'une autre, avaler l'excpetion est sans danger, car cela n'a aucune incidence sur l'état de la base de données.
2. regardant la source de SnaqDB CacheConnection, les délégués de la méthode isClosed à la connexion sous-jacente. Donc, le problème n'est pas là, mais se trouve avec le contrat défini pour isClosed() et Connection.close() lançant une exception.