Mise en veille prolongée SQLQuery court-circuite cache de session mise en veille prolongée

Question

Je suis « transactionalizing » une certaine manipulation de base de données complète et je suis tombé sur cette question où, si j'exécuter des requêtes SQL par le biais de mise en veille prolongée, mais pas en utilisant l'approche MQL, la vue de la base de données ne semble pas correcte. Plus précisément, le code utilise la mise en veille prolongée de la manière plus appropriée dans la plupart des cas, mais il y a des endroits où quelqu'un a décidé d'exécuter juste sql. Je ne aime pas ce qu'ils ont fait cela, mais à ce stade « il est ce qu'il est ».

J'ai trouvé un

Était-ce utile?

Nous faire parvenir

La solution

Votre question est source de confusion, mais je suppose que vous dites que Hibernate ne cherche pas des entités dans le cache de session lorsque vous effectuez des requêtes natives.

requête SQL, ou natif de requête, est une requête qui Hibernate relaie juste à la base de données. Mise en veille prolongée ne sera pas analyser la requête, et il ne sera pas analyser les résultats. Hibernate, cependant, laissez-vous gérer les résultats, pour convertir les colonnes en propriétés d'une classe. Cela dit, il semble tout à fait naturel que les Requêtes natives contournerait le cache de session. En effet, Hibernate ne sait rien au sujet de votre requête, ni sur les « résultats » de cette requête (qui ne sont pas des objets à ce moment-là).

Answer 1

Votre question est source de confusion, mais je suppose que vous dites que Hibernate ne cherche pas des entités dans le cache de session lorsque vous effectuez des requêtes natives.

requête SQL, ou natif de requête, est une requête qui Hibernate relaie juste à la base de données. Mise en veille prolongée ne sera pas analyser la requête, et il ne sera pas analyser les résultats. Hibernate, cependant, laissez-vous gérer les résultats, pour convertir les colonnes en propriétés d'une classe. Cela dit, il semble tout à fait naturel que les Requêtes natives contournerait le cache de session. En effet, Hibernate ne sait rien au sujet de votre requête, ni sur les « résultats » de cette requête (qui ne sont pas des objets à ce moment-là).

Answer 2

En fait, le blog « explication » par Chris Landry manque 3 méthodes API importantes de SQLQuery et c'est en fait pourquoi il a ces problèmes. Plus particulièrement, (1) addSynchronizedQuerySpace, (2) addSynchronizedEntityName et (3) addSynchronizedEntityClass

Comme partenon souligne, juste basée sur la chaîne de requête SQL Hibernate lui-même n'a aucun moyen de savoir quelles sont les tables et / ou entités sont interrogés dans la requête. Par conséquent, il n'a aucune idée de ce que les changements mis en attente dans la nécessité session d'être envoyé à la base de données. Dans le blog Chris n'indique que vous pouvez effectuer un appel flush () sur votre propre avant d'exécuter la requête SQL. Cependant, ce que je décris est la capacité flush automatique de mise en veille prolongée. Il ne fait la même chose pour les requêtes HQL et critères. Seulement là, il sait les tables affectées. Quoi qu'il en soit, ce processus d'auto-rinçage fait un rinçage « rinçage minimal » seules choses qui affectent la requête. C'est où ces méthodes entrent en jeu.

À titre d'exemple, la requête SQL Chirs est

session.createSqlQuery("select name from user where name = :userName")

Vraiment tout ce qu'il devait faire était de dire ...

session.createSqlQuery("select name from user where name = :userName")
        .addSynchronizedQuerySpace( "user" )

Le addSynchronizedQuerySpace( "user" ) est dit Hibernate que la requête utilise une table nommée « utilisateur ». Maintenant, Hibernate peut automatiquement flush toutes les modifications en attente pour les entités mises en correspondance à cette table utilisateur.