Parce qu'il y en marre d'écrire des pom.xml de 2000 lignes

Si comme moi vous développez en java, il y a des chances que vous perdiez pas mal de temps à écrire et à tester des énormes fichiers pom.xml (maven). Vous me direz qu'avec Gradle, on remplace le xml par du Groovy déjà moins verbeux et plus souple, c'est pas faux. Cela dit à mon avis ce serait 100 fois plus simple pour un développeur java de pouvoir écrire son build tout simplement en java.

J'ai voulu tester l'idée donc j'ai fait un poc de plugin maven qui permet de plugguer des classes java custom directement dans les phases de build maven. Il suffit de placer ces classes dans le projet dans un dossier src/build/java puis d'insérer une annotation pour indiquer quand maven doit les exécuter dans le lifecycle.

Ex :




En fin de compte, on garde dans le pom.xml les infos essentielles du projet (dépendances, scm...) mais pour tout ce qui est plus "custom", plus besoin de s'arracher les cheveux avec un plugin maven compliqué et mal documenté, plus besoin de maven-antrun-plugin (beurk !), on code directement en java dans le projet ex :

• générer des classes java
• scanner le projet à la recherche de certaines annotations (ce qu'on fait habituellement au runtime avec Spring et qui coute super cher en temps de démarrage)
• générer des pages de doc
• lancer une base embarquée avant les tests unitaires
• utiliser les nombreuses librairies qui existent et permettent de faire toutes sorte de choses mais n'ont pas de plugin maven
• tout autre chose qu'on ne peut pas faire facilement avec un plugin maven existant
• ...

Le code est ici avec un exemple : https://github.com/fxbonnet/builder

Si ça intéresse suffisamment de monde (le nombre de ★ dans github faisant foi), je le déploierai sur le repository central maven.

Peut-on partager une connection JDBC entre plusieurs threads ?

Pourquoi faire ?

J'ai une application web qui fait de la lecture seule sur une base de données. Donc pas besoin de transactions, d'isolation et tout ça... Dans ce cas pourquoi s’embêter à gérer un pool de connection, ce serait plus simple d'utiliser une seule connection partagée par tous les threads de mon application.

Réponse :
D'autres s'étaient posé la question avant moi. En recherchant sur Google, la réponse est oui, mais...

J'ai trouvé plein de discussions sur le sujet. En synthèse :

• la spec JDBC dit que les connections doivent être thread-safe mais pas de précisions sur les use-cases
• en pratique tout le monde dit que le bon pattern c'est une connection par thread et que certains drivers ne sont sans doute pas thread-safe
• selon les documentations, au moins dans les drivers Oracle et PostgreSQL les connections sont thread-safe (je ne sais pas pour les autres SGBD)
• en pratique c'est implémenté à grands coups de synchronized donc pour les performances, c'est mort : les requêtes lancées par les différents threads vous s'exécuter l'une après l'autre et non en parallèle, la connection va devenir le goulet d'étranglement de l'application

Donc on peut le faire, mais il ne faut pas le faire. Mieux vaut le pattern classique 1 connection par thread.

Quelques liens intéressants sur le sujet :

• https://jdbc.postgresql.org/documentation/92/thread.html
• https://www.linkedin.com/groups/Is-JDBC-connection-thread-safe-70526.S.228870700
• http://stackoverflow.com/questions/1531073/is-java-sql-connection-thread-safe
• http://docs.oracle.com/cd/B14117_01/java.101/b10979/tips.htm#i1005436
• http://appcrawler.com/wordpress/2011/06/21/multiple-threads-using-same-physical-connection/