Article complet: JDBC est-il plus rapide que JPA ?

En ce moment, je réécris totalement le code serveur du site Edupassion.com. Et après avoir découvert JPA il y a seulement quelques semaines, je suis maintenant sûr que la plupart des accès à la base de données d'Edupassion seront fait en JPA : plus simple à maintenir.

Cependant certaines requêtes seront très fréquemment utilisées par les utilisateurs : l'accès aux tokens d'authentification, et l'accès aux notes pour les profs et élèves. Il me parait donc logique de faire du JDBC pour optimiser ces deux-trois cas d'utilisation. Mais JDBC est-il vraiment plus rapide ? JPA vs JDBC : voici ce que j'ai trouvé sur java.net :

[Suite:]

L'architecture est plus importante que la technologie :

[QUOTE]
The performance is completely
dependent on what you want to achieve and what actual providers you are
using. You should decide for a technology on a design or architecture
level. If you really want to decide on a performance level, you have not
understood what both are good for. Both are neither competitive, nor
comparable.
[/QUOTE]

A première vue, cela ne m'apporte rien. Un visiteur passe donc apporter la contradiction : puisque JPA est basé sur JDBC, un excellent programmeur serait capable de faire toujours mieux avec JDBC qu'avec JPA. Encore faudrait-il qu'un bon développeur existe - cela me rappelle Lex&Yacc ...

[QUOTE]
With JPA vs JDBC, this is exactly the same. JDBC is the building block upon which JPA is built. JPA (as a result of standing on the
shoulders of JDBC) can never be faster than _properly tuned_ raw JDBC.
However, the JDBC code that most developers will write is going to be
slower than JPA 99% of the time...
[/QUOTE]

La réponse qui tue : JPA et JDBC n'ont pas le cache au même endroit (?!).

[QUOTE]
the JPA cache is on the client side, while the JDBC / DBMS cache is on the server side. Assuming a JDBC-based JPA implementation, you will benefit from this double buffering (if you have luck, the object is in the client side JPA cache; if you have not so good luck, it is found in the server side JDBC / DBMS cache; if you have bad luck, you must go down to the hard disc). If you do JDBC on the client side, then there is no client cache (unless your particular driver vendor implemented one directly in the client side driver). So, a JPA query will return client side cached objects, while a JDBC query must forward the server side cached data over the LAN. In sum, you have far more LAN transport with JDBC than with JPA. Unless you have client and server on the same machine, what is untypical in Client-/Server computing
[/QUOTE]

Pour ce que j'arrive à traduire et surtout comprendre, plus la quantité de données échangées entre JPA/JDBC et le serveur MySQL est importante à chaque requête, plus il est préférable de s'orienter vers JPA. Pour récupérer un token, ce serait JDBC, alors que pour récupérer un ensemble de notes dispersées entre plusieurs classes, groupes et périodes, ce serait JPA.

Ce dernier point me fait dire que si je veux faire du benchmarking, il n'aurait pas grand sens. A court terme, ma base de données est évidemment sur le même serveur, mais si j'ai un peu de succès, ca ne sera plus le cas.