Il y a 12 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.
Tous les podcasts Xebia France :
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.engineering.publicissapient.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 "
Published by Jonathan , Il y a 12 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.
Published by Lambda , Il y a 12 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 :) ).
Published by adiGuba , Il y a 12 ans
Personnellement je suis plutôt un adepte du fait d’utiliser un try/finally par ressource, suivant ce pattern :
[code]// 1 – Création de la ressource
try {
// 2 – Utilisation de la ressource
} finally {
// 3 – Libération de la ressource
}[/code]
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***()) :
[code]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();
}[/code]
a++
Published by Cyrille Le Clerc , Il y a 12 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 :-)
Published by adiGuba , Il y a 12 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++
Published by Cyrille Le Clerc , Il y a 12 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
Published by adiGuba , Il y a 12 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++