Discussion :

[Tom1x]

Bonjour,

Je développe un site internet en Java EE, sa base de données ne contient pas énormément de tables (~10) pensez vous qu'il serait plus judicieux d'utiliser JPA ou plutôt JDBC sachant que le site devrait à moyen et long terme supporter plusieurs centaines de connexions.

J'ai vu que JPA une fois mis en place facilite le développement grace notamment à sa gestion d'erreurs mais aussi permet une meilleure sécurité mais peut être plus lourd aussi.

Qu'en pensez vous ?

Merci pour vos réponses !

[tchize_]

JPA c'est comme JDBC: c'est pratique, bien utile, mais ça peux vite tuer tes performances si tu l'utilise mal. Donc ce n'est pas la question de JPA ou pas JPA que tu dois te poser mais plutot bien lire la doc de JPA pour ne pas faire l'andouille.

et JPA s'en fou du nombre de connexions que tu as. Entre faire du jdbs et transférer dans un DAO tes données ou faire JPA qui fait exactement le même boulot, ça change pas grand chose. L'avantage de JPA c'est que si quelqu'un arrive après sur ton code, il comprendra tout de suite comment travailler. Avec les DAO maison, ce sera tout de suite compliqué et grevé de edge case.

[Tom1x]

Merci tchize_ pour ta réponse.

En terme de sécurité JDBC et JPA sont égaux alors ?

Je pense que je vais partir sur du JPA et creuser la documentation, le site devra subir plusieurs évolutions et pas forcément par les même développeurs donc c'est la meilleure chose à faire.

Au passage, je dois choisir un serveur d'application, j'ai utilisé uniquement Wildfly dans mon expérience précédente. Mais j'ai vu que niveau performance ce n'était pas le meilleur choix en tout cas pour un site web lors de lourdes charges, j'ai vu que plusieurs sites utilisaient Nginx mais je ne crois pas qu'il prend en charge les spécifications de Java EE je me trompe ?

J'avais pensé sinon utiliser Tomcat (TomEE pour utiliser JPA) et éventuellement le coupler à Nginx .. c'est possible ?

Si vous avez des conseils à me donner, je suis preneuse !

[Pill_S]

JavaEE n'est pas nécessaire pour faire du JPA, tu peux te mettre dans n'importe quel container (et même sans container) - j'ai fait du JPA sous Tomcat, ça marche bien, et on peut aussi en faire en mode JavaSE.

JavaEE va notamment amener JTA - les transactions distribuée sur plusieurs ressources, avec commits en 2 passes; tu peux par exemple coordonner des opérations sur plusieurs databases, des envoi de messages sur des ESB en JMS, des manipulations du filesystem, enfin bref tout ce qui est capable de fournir une implémentation XA Resource, etc. et soit toutes les opérations fonctionnent et sont committées, soit elles sont toutes rollbackées.

Dans un soucis de KISS (Keep It Stupidly Simple), si tu n'as pas besoin de quelque chose fourni uniquement par JEE, autant rester sur du container léger - Tomcat fait un super boulot pour pratiquement 90% des besoins courants, donc avant de l'écarter, je réfléchirais bien...

En ce qui concerne nGinx, je pense qu'il suffit de configurer le reverse proxy correctement et c'est tout bon - mais je ne l'ai jamais fait.

[tchize_]

le truc c'est que NGinx est performant quand il fournis des sites... statiques Il ne faut pas confondre un site web et une application javaEE. Le web n'est que le front end dans une application javaEE. On peut faire une application javaEE sans front end web comme on peut faire un site web sans javaEE.

Si tu as énormément de ressources statiques à fournir, déporte les dans un front-end (apache httpd, nginx, etc) et ne garde que la partie dynamique dans le serveur java backend (tomcat, wildflyt, websphere, ...) pour gagner en perfs. Des sites découplés avec du REST + XmlHttpRequest s'y prêtent bien mais ce n'est pas exclusif.

Si maintenant la majorité de ton site est dynamique et généré par le serveur java, mettre un front-end comme nginx ne t'apportera pas grand chose si ce n'est une petite couche de sécurité intermédiaire, puisque tout ira de toutes façons tapper sur le serveur dynamique en backend.

Pour info, j'ai bossé à un endroit où l'on se tappait de pics de visite imprévisibles de l'ordre de centaines de milliers de visites en 1h. Dans ce genre de condition, t'es obligé de sortir l'artillerie des CDN pour t'en sortir Même si ton serveur tiens le coup, c'est ta bande passante qui lâche.

[Gugelhupf]

J'utilise JPA si c'est une application de gestion avec des modèles car c'est pratique, pour des besoins plus spécifiques (ex: utilisation de requête SQL complexes, calculs etc) j'utilise JDBC.

En terme de sécurité tu peux aussi bien créer des failles avec JPA que JDBC si tu ne fais pas attention aux injections SQL, avec JPA le risque est moindre car tu utilises des objets pour les opérations de type INSERT/UPDATE/DELETE.

Si tu travailles dans un environnement Java EE (un vrai, pas Tomcat ou Jetty, c'est-à-dire : TomEE, GlassFish, JBoss/WildFly etc), je te conseille d'utiliser JPA en mode JTA au lieu de resource local pour que les transactions soient gérés implicitement.

[Tom1x]

Bonjour,

Je vous remercie pour vos réponses, elles m'aident énormément !

Je n'ai pas saisie l'avantage de JTA sur JPA ? Dans quel cas est il préférable d'utiliser plus l'un que l'autre ?

Par exemple je peux utiliser JTA avec Tomcat en important les jars JTA dans mon répertoire lib ? Il vaut mieux faire cela qu'utiliser TomEE selon vous ? (Dans le cas ou je n'ai pas besoin d'utiliser d'autres spécifications de Java EE par exemple)

J'ai quelques ressources statiques comme la FAQ, pages d'informations et quelques ressources dynamiques (commentaires, annonces, profil etc..)
Selon vous l'utilisation de Nginx apporterait elle une plus value en terme de performance dans ce cas ?

TomEE est il plus léger que WildFly ?

@tchize_ : Je ne connaissait pas les CDN merci pour l'information, c'est très intéressant, que penses tu de CloudFlare ?

[Pill_S]

JTA ne remplace pas JPA. Il s'y ajoute pour apporter le support des transactions distribuées (plusieurs ressources hétérogènes coordonnées pour se commiter ou se rollbacker ensemble).

JTA n'existe de base que dans JEE - même si il existe des transaction manager JTA pour le monde non-JEE (JOTM, Atomikos, Bitronix, etc...) mais c'est un peu foireux (ils ne sont pas tous d'un niveau de qualité comparable). Si besoin de JTA, alors mieux vaut passer en mode full-JEE (WildFly, TomEE, ...).

Pour les CDN, je connais et ai eu l'occasion d'utiliser Akamaï, mais c'est du lourd de chez lourd - il est rare d'en avoir besoin, mais si le besoin est là, ça permet d'avoir des temps de réponses identiques quel que soit la localisation de l'utilisateur, et quel que soit la charge (monte facilement en charge).

[tchize_]

@tchize_ : Je ne connaissait pas les CDN merci pour l'information, c'est très intéressant, que penses tu de CloudFlare ?

Je ne connais pas, mais je sais que pour débuter avec un CDN, ovh fait très bien le boulot pour un prix ridicule par rapport à celui de Akamai. Me souvient de leur tête quand ils nous présenté toute leur offre et options puis qu'on leur a lâché: notre budget est de 1000€/ an (leur offre à l'époque commençait à 40.000)
Note qu'un CDN c'est un truc que tu amène en général après coup, quand tu constate que ton infra ne suis plus à force de grossir. J'ai du mal à imaginer un nouveau projet qui dès le départ se dit "on va balancer 100TB par mois de données vers nos clients"

[OButterlin]

La question de base à se poser pour le choix entre JDBC ou JPA est plutôt de l'ordre :
- je fais de la gestion des données
- je fais des requêtes à gogo.

Je m'explique :
Pour gérer des enregistrements en mise à jour, JPA est très bien, facilite effectivement le travail du développeur. Par contre, quand il s'agit de faire de la requête lourde sur beaucoup d'enregistrements, les performances peuvent très vite s'effondrer. Si on ne fait pas gaffe, on peut se retrouver avec tout le graphe d'objets en mémoire avec quelques accès.

Pour ça, JDBC est beaucoup plus performant parce qu'il permet des choses beaucoup plus pointues. Par exemple, tu pourras choisir un index plutôt qu'un autre en fonction de ce que tu recherches, ou des vues, ce qui optimisera forcément les choses.
Avec JPA, on ne gère que des tables...

Si tu connais bien SQL, je dirais que JDBC est plus naturel.
JPA demande un apprentissage et une connaissance minimum des mécanismes sous-jacents.