Hibernate SQLQuery bypasses hibernate session cache

Question

I am “transacting” some extensive database manipulations, and I came across this problem when, if I run sql queries through sleep mode, but not using the MQL approach, the database view does not look right. In particular, the code most often uses hibernation in most cases, but there are places where someone decided to just execute sql. I don’t like the fact that they did it, but at the moment "this is what it is."

I found an explanation that seems to explain this, but all the examples actually get and control the transaction into the code. We use the @TransactionAttribute annotation for the entire class to modify this code and find many places where this happens, but I'm not quite sure the explanation applies to code that is simply wrapped in the annotation - I assumed that everything that the hibernation manager would use would be rely on the cache of the object in the session.

Sorry in advance if I mean concepts in sleep mode using the wrong terminology, etc.

Answer 1

Your question is confusing, but I assume that you are saying that Hibernate is not looking for objects in the session cache when you execute your own queries.

SQL Query or Native Query is a query that Hibernate simply passes to the database. Hibernate will not parse the query, and it will not parse the results. Hibernate, however, will allow you to process the results to convert columns to class properties. However, it is only natural that Native Queries will bypass the session cache. This is because Hibernate knows nothing about your query and the "results" of this query (which are not objects at this point).

Answer 2

In fact, Chris Landry’s “explanation” blog skips 3 important SQLQuery API methods, and in fact, why he has such problems. In particular, (1) addSynchronizedQuerySpace, (2) addSynchronizedEntityName and (3) addSynchronizedEntityClass

As partenon points out, based on the SQL query string itself, Hibernate has no way of knowing which tables and / or entities are being requested in the query. Therefore, he does not know what changes in the queue for the session need to be dumped to the database. On a blog post, Chris points out that you can make a flush () call yourself before running an SQL query. However, what I am describing is the ability to automatically launch Hibernate. This actually does the same for HQL and Criteria queries. Only there he knows which tables are affected. In any case, this automatic flushing process makes the "minimum flash" flush only those that affect the request. Where these methods come into play.

As an example, a Chirs SQL query

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

Indeed, all he had to do was say ...

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

addSynchronizedQuerySpace( "user" ) tells Hibernate that the query uses a table named "user". Hibernate can now automatically flush all changes pending for objects mapped to this user table.