Il y a 8 ans -

Temps de lecture 1 minute

Gestion des ressources par Cyrille Le Clerc

Si vous êtes lecteur de notre blog, vous avez probablement entendu parler des journées XKE. Organisées une fois par mois, cette journée est dédiée aux échanges techniques et humains entre les consultants. Nous souhaitons partager avec vous l’une de ces sessions en vidéo. La session, animée par Cyrille Le Clerc, concerne la gestion des ressources en Java, et plus particulièrement leur fermeture.

Gestion des ressources par Cyrille Le Clerc



Tous les podcasts Xebia France :

  • Subscribe with iTunes
  • Xebia France Podcast Feed

Publié par Xebia France

Xebia est un cabinet de conseil international spécialisé dans les technologies Big Data, Web, les architectures Java et la mobilité dans des environnements agiles. Depuis plus de 15 ans, nous avons la volonté de partager notre expertise et nos actualités à travers notre blog technique.

Publié par Cyrille Le Clerc

CTO de Xebia, Cyrille est aussi committer sur le projet Apache CXF. Après être récemment intervenu sur les sites web et les plateformes de web service à fort traffic d'opérateurs de télécommunication, Cyrille est actuellement responsable de la mise en place d'une grille de données inter-continentale pour une grande institution financière française. Après 7 ans chez IBM Global Services et 5 ans chez Xebia, Cyrille a une expérience variée allant du monde commercial aux écosystèmes Open Source dans des approches aussi bien très cadrées et contractuelles que légères et agiles. Cyrille est aussi blogger sur blog.xebia.fr et speaker dans des conférences (In Memory Data Grids & NoSQL, applications prêtes pour la production, etc).

Commentaire

7 réponses pour " Gestion des ressources par Cyrille Le Clerc "

  1. Publié par , Il y a 8 ans

    En passant, dans d’autres langages sur la JVM, on peut un peu plus facilement gérer ce genre de problématique avec moins de « boilerplate code ».

    Exemple en Scala : https://gist.github.com/1068327

    C’est type safe, et ça marche avec JDBC ou les readers, ça doit marcher avec JMS tel quel ou en surchargeant.

    Quid des exceptions ? Il faudra juste faire un match dessus, rien de particulier pour du code Scala, ou mettre un @throws(classOf

    
    

    ) sur les méthodes qui pourraient être appelée de Java.

  2. Publié par , Il y a 8 ans

    Merci beaucoup, c’était très intéressant, je m’étais toujours demandé comment gérer ce genre de choses, désormais je sais quoi faire (et j’ai rajouté findbugs dans mon projet :) ).

  3. Publié par , Il y a 8 ans

    Personnellement je suis plutôt un adepte du fait d’utiliser un try/finally par ressource, suivant ce pattern :

    // 1 - Création de la ressource
    try {
        // 2 - Utilisation de la ressource
    } finally {
        // 3 - Libération de la ressource
    }

    Cela génère un peu plus d’indentation, mais ca permet de libérer la ressource au plus tôt, le tout sans ignorer aucune exception (contrairement aux méthodes JdbcUtils.close***()) :

    final Connection con = dataSource.getConnection();
    try {
    	final Statement stmt = cnn.createStatement();
    	try {
    		final ResultSet rs = cnn.executeQuery("seect first_name from customer");
    		try {
    			while (rst.next()) {
    				System.out.println(rst.getString("first_name"));
    			}
    		} finally {
    			rs.close();
    		}
    	} finally {
    		stmt.close();
    	}
    } finally {
    	con.close();
    }

    a++

  4. Publié par , Il y a 8 ans

    @adiGuba

    Merci pour votre retour d’expérience.

    Je comprends votre souhait de ne pas ignorer les exceptions levées par l’appel des méthodes « .close() ». Cependant, je préfère les suivre avec un logger plutôt que de perdre l’exception qui a réellement causé l’interruption de mon code.
    Je trouve que les JdbcUtils.closeXxx() et JmsUtils.closeXxx() de SpringFramework ne masquent pas vraiment les exceptions des appels à « .close() » puisqu’elles les loggent en DEBUG.

    Sur le fond, l’essentiel est tout de même de « closer » ces resources !

    Cyrille qui doit aujourd’hui fixer une fuite connexion JMS dans du code :-)

  5. Publié par , Il y a 8 ans

    Oui… mais au niveau de l’application ces exceptions passent inaperçu :(
    Et dans certains cas cela peut s’avérer problématique.

    Par exemple si on utilise un BufferedOutputStream, l’appel à close() peut générer une écriture des données présentes dans le buffer. Une erreur peut donc correspondre à une perte de donnée qui devrait avoir un impact sur le déroulement programme…

    Enfin… Le try-with-ressources de Java 7 mettra tout le monde d’accord :D

    a++

  6. Publié par , Il y a 8 ans

    @adiGuba

    1. je viens de regarder le code de BufferedOutputStream, il « swallow » l’exception du « flush() » appelé dans le « close() » :-)

    2. Google Guava’s Closeables.closeQuietly() émet les messages d’erreur au niveau WARN

    3. Si une classe utilitaire ne fait pas exactement ce que je veux, je dégaine mon utilitaire XxxUtils2 pour traiter mon besoin :-)

    mais sur le fond nous sommes sur la même longueur d’onde !

    Cyrille

  7. Publié par , Il y a 8 ans

    1) Rôh les barbares ! Je ne m’attendais vraiment pas à cela !
    C’est très con, car je viens de vérifier et dans BufferedWriter ce n’est pas le cas ! 8|

    Bon ben va falloir que je m’habitue à flusher explicitement tous mes flux :/

    a++

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.