Discussion :

[tdeco]

Bonjour
J'ai remarqué une différence de temps de réponse entre une requête count en HQL et en SQL sur Oracle. Le code de ma requête HQL est semblable à celui-ci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
...
Query hibernateQuery = this.getSession().createQuery("select count(*) from ...");
long count = ((Long) hibernateQuery.uniqueResult()).longValue();

Cette requête prend 5 secondes pour 3020 enregistrements comptés.

Après avoir passé le paramètre hibernate.show_sql à true. J'ai exécuté la requête SQL générée, avec la méthode createSQLQuery. Celle-ci répond en moins d'une seconde. J'ai le fait le même test sur un client Oracle, j'observe le même temps de réponse.
Quelqu'un peut m'expliquer cette différence de temps en HQL et SQL. Faut-il privilégier le SQL au lieu du HQL pour ce genre de requête ?
Merci d'avance

[tchize_]

et si vous inversez l'ordre des deux requetes, l'avantage est toujours au même?
et si vous faites plusieurs fois l'opération dans hibernate, le temps reste le même? Difficile de conclure à une règle général a partir d'une mesure particulière

[tdeco]

En faisant plusieurs fois l'opération dans hibernate, le temps n'est pas le même. A la première éxécution, le temps de réponse est égal à 5 secondes, puis inférieur à 1 seconde. Je pense que cela vient du temps de calcul du plan d'exécution par le moteur SQL. Vu que dans ma requête il y a des jointures assez complexes, cela prend du temps

[tchize_]

ça ou vous avez inclus dans la mesure le démarrage d'hibernate, qui prend du temps.

[tdeco]

Il y a d'autres requêtes avant la requête qui pour moi posait problème.

[tchize_]

attention qu'avant un select, hibernate fait un flush de ses données! ça pourrait jouer sur vos performances.

[tdeco]

attention qu'avant un select, hibernate fait un flush de ses données! ça pourrait jouer sur vos performances.

C'est seulement dans le cas où on n'est pas dans la même session non ?

[tchize_]

au contraire, pour que le résultat de la requete HQL (qui passe par la DB) soit correct, il faut que la DB corresponde à la session hibernate, donc la session, si elle a des modifications, va être flushée vers la DB pour la mettre à jour avant de faire la requete. Sinon on aurait ce genre de chose

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Personne p = new Personne("Tartempion");
s.saveOrUpdate(p);
List personnes = s.createQuery("from Personne").list();

et magie, tartempion n'apparaitrais pas dans la liste de personnes, ce qui serait incohérent.

[OButterlin]

C'est plutôt étonnant ce que tu dis là.
Dans la mesure où on est dans la même session (donc Connection), le select voit l'ajout même s'il n'est pas "commité".
Tu es sûr de ce que tu avances ?
Pour moi, il est inconcevable qu'un flush soit fait avant un select, il doit attendre l'instruction explicite commit.

[Rei Ichido]

C'est pourtant bien le cas.

10.10. Flushing the Session

Sometimes the Session will execute the SQL statements needed to synchronize the JDBC connection's state with the state of objects held in memory. This process, called flush, occurs by default at the following points:

* before some query executions
* from org.hibernate.Transaction.commit()
* from Session.flush()

Ce qui semble assez logique, pour la raison évoquée par Tchize.
Ensuite, le Flush envoie l'instruction de modif à la DB (insert/delete/update), ce qui est différent de faire un commit de la Transaction (qui peut cependant être automatique selon le mode de Flush).

[OButterlin]

Moi, ce que je lis, c'est "before SOME query executions".
Ce qui laisse supposer que c'est dans certains cas et pas systématiquement.
Je comprendrais qu'il y ait un lien avec le niveau d'isolation mais sinon, j'espère bien que ce n'est pas le cas.

Voici un exemple qui poserait problème:
(1)- Recherche d'éléments à mettre à jour
(2)- Pour chaque élément, affectation de certains champs
(3)- Recherche connexe pour d'autre informations <-- Et c'est là que ça coince
(4)- En fonction du résultat, validation de la mise à jour ou non

Si à la recherche connexe il faisait un flush qui valide en DB les modifications en attente de (2)

[tchize_]

le HSQL n'est qu'un traducteur qui va transformer ta requete en SQL en respectant les règles de mapping pour ensuite récupérer les IDs sur la DB via cette requête SQL. De fait tout ce qui se trouve en session doit donc se trouver sur la DB, sinon il ne sera pas dans les résultat. Analyser le graphe d'objet en mémoire pour voir si il matche la requete, c'est faire supporter par hibernate un travail et un poids que, a priori, la database gère très bien.

Enfin, il ne faut pas confondre le flush et le commit. Ca ne pose aucun problème que hibernate flush les données. Tant qu'elle ne sont pas commitées, ca n'influence pas les autres sessions.

Enfin, si tu as déjà fait tourner des application Hibernate avec du show_sql à true, les patterns de flush juste avant le query, tu les vois passer à la pelle

[tchize_]

Si à la recherche connexe il faisait un flush qui valide en DB les modifications en attente de (2)

1) Ne confond pas le flush et le commit
2) si tu n'a pas demandé à hibernate de persister le changement de champ que tu as fait (session.saveOrUpdate(objet) par exemple), il n'y aura rien dans le flush car aucune modif validée. C'est le saveOrUpdate et le commit qui valident la modif des objet, jamais le flush, tu ne devrais meme pas savoir qu'il existe, c'est juste technique

[OButterlin]

C'est le saveOrUpdate et le commit qui valident la modif des objet, jamais le flush, tu ne devrais meme pas savoir qu'il existe, c'est juste technique

Il est clair que je ne l'ai jamais utilisé, mais la doc d'Hibernate n'est pas très clair non plus sur le mécanisme, on sait juste que ça concerne une mise à jour du cache.
Bref, on ne va pas épiloguer