Fermeture des connexions JDBC dans le pool

Question

Notre section de code standard pour l'utilisation de JDBC est...

Connection conn = getConnection(...);
Statement  stmt = conn.conn.createStatement (ResultSet.TYPE_SCROLL_INSENSITIVE,
                                                ResultSet.CONCUR_READ_ONLY);
ResultSet  rset = stmt.executeQuery (sqlQuery);

// do stuff with rset

rset.close(); stmt.close(); conn.close();

Question 1 : Lorsque l'on utilise le pool de connexion, doit-on fermer la connexion à la fin ? Si c'est le cas, le but de la mise en commun n'est-il pas perdu ? Et sinon, comment la source de données sait-elle quand une instance particulière de connexion est libérée et peut être réutilisée ? Je suis un peu perdu sur ce point, toute indication sera appréciée.

Question 2 : La méthode suivante est-elle proche de la norme ? On dirait une tentative d'obtenir une connexion à partir du pool et, si la source de données ne peut être établie, d'utiliser le bon vieux DriverManager. Nous ne sommes même pas sûrs de la partie qui est exécutée au moment de l'exécution. Je répète la question précédente : doit-on fermer la connexion qui sort d'une telle méthode ?

Merci, - MS.

synchronized public Connection getConnection (boolean pooledConnection)
                                                        throws SQLException {
        if (pooledConnection) {
                if (ds == null) {
                        try {
                                Context envCtx = (Context)
                                        new InitialContext().lookup("java:comp/env");
                                ds = (DataSource) envCtx.lookup("jdbc/NamedInTomcat");
                                return ds.getConnection();
                        } catch (NamingException e) {
                                e.printStackTrace();
                }}
                return (ds == null) ? getConnection (false) : ds.getConnection();
        }
        return DriverManager.getConnection(
                "jdbc:mysql://"+ipaddy+":"+dbPort +"/" + dbName, uName, pWord);
}

Edit : Je pense que nous obtenons la connexion mutualisée puisque nous ne voyons pas de trace de pile.

Answer 1

Lorsqu'on utilise le pool de connexion, doit-on fermer la connexion à la fin ? Si c'est le cas, le but de la mise en commun n'est-il pas perdu ? Et sinon, comment la source de données sait-elle quand une instance particulière de connexion est libérée et peut être réutilisée ? Je suis un peu perdu sur ce point, toute indication sera appréciée.

Oui, il est certain que vous devez également fermer la connexion mutualisée. C'est en fait une enveloppe autour de la connexion réelle. Il libère sous le manteau la connexion réelle vers le pool. C'est ensuite au pool de décider si la connexion réelle sera en fait être fermé ou être réutilisé pour une nouvelle getConnection() appel. Donc, que vous utilisiez un pool de connexion ou non, vous devez toujours fermez toutes les ressources JDBC dans l'ordre inverse dans le fichier finally du bloc try bloc où vous les avez acquis. Dans Java 7, cela peut être encore simplifié en utilisant try-with-resources déclaration.

---

La méthode suivante est-elle proche de la norme ? On dirait une tentative d'obtenir une connexion à partir du pool et, si la source de données ne peut être établie, d'utiliser le bon vieux DriverManager. Nous ne sommes même pas sûrs de la partie qui est exécutée au moment de l'exécution. Je répète la question précédente : doit-on fermer la connexion qui sort d'une telle méthode ?

L'exemple est assez effrayant. Vous avez juste besoin de rechercher/initialiser la fonction DataSource une seule fois pendant le démarrage de l'application dans un constructeur / initialisation d'une classe de configuration de la base de données pour toute l'application. Ensuite, il suffit d'appeler getConnection() sur une seule et même source de données pendant toute la durée de vie de l'application. Pas besoin de synchronisation ni de contrôles nuls.

Voir aussi :

• Est-il sûr d'utiliser une instance statique de java.sql.Connection dans un système multithread ?
• Est-ce que j'utilise la mise en commun des connexions JDBC ?

Answer 2

Les pools vous renvoient généralement un objet Connexion enveloppé, où la méthode close() est surchargée, renvoyant généralement la Connexion au pool. L'appel de close() est acceptable et probablement toujours nécessaire.

Une méthode close() ressemblerait probablement à ceci :

public void close() throws SQLException {
  pool.returnConnection(this);
}

Pour votre deuxième question, vous pourriez ajouter un enregistreur pour indiquer si le bloc inférieur fonctionne. J'imagine cependant que vous ne voudriez que l'un ou l'autre pour la configuration de vos connexions à la base de données. Nous utilisons uniquement un pool pour nos accès aux bases de données. Dans tous les cas, il est important de fermer la connexion pour éviter les fuites.

Answer 3

En fait, la meilleure approche de la gestion des connexions est de ne pas les confier à un code quelconque.

Créez une classe SQLExecutor qui est le seul et unique emplacement qui ouvre et ferme les connexions.

Tout le reste de l'application pompe alors des instructions dans l'exécuteur au lieu d'obtenir des connexions du pool et de les gérer (ou de les mal gérer) partout.

Vous pouvez avoir autant d'instances de l'exécuteur que vous le souhaitez, mais personne ne doit écrire de code qui ouvre et ferme des connexions en son nom propre.

De façon pratique, cela vous permet également d'enregistrer tout votre SQL à partir d'un seul ensemble de code.