Hi .
I am using Hibernate inside user transaction and doing the following acations:
1. session.delete(obj); (not flush after).
2. select with Native Query (session.createSQLQuery(....))

The select action see records that was deleted throw the delete action .(ignoring the delete).
I have two question :
1. Why native query dont see the changes ? (i guess session.get see them).
2. What is flush inside user transaction does ? (is there a good reason why not to flush inside transaction).

thanks in advance .
p.s
I will be happy if some one can explaine the mechanism of native query vs get as well.

I cannot give you the answer to this question,
but I can tell you that hibernate queries in general (therefore also HQL and Criteria) are not
filtering deleted entity objects from result-set.



With flush the deletion is propagated to the database, so the returned result-set should not contain deleted objets anymore



There are some reasons against flushing during the transaction:
1. flush may throw exceptions which you otherwise will get only at commit time
Therefore a good code, should encapsulate flushing queries into a try-catch block and handle the exceptions properly
2. flush may create WRITE-LOCKs on the database and these are not released until you commit or rollback the transaction.
During this time-window other users (transaction) may get blocked or run into locktimeout exception due these WRITE-LOCKs
3. Flush actions can be cpu-intensive and slow down your application if they are called often and if your persistent context is big (=many entities and collections loaded)

Because the changes that you have made *may* may not have flushed (written) to the database.
See this paragraph: http://docs.jboss.org/hibernate/core/3. ... ns-working

Hi justinwalsh,


I believe that we all including shmuelb,are aware of the fact,
that the query don't returns the deleted objects anymore once we call flush.

I think the real question is following:
why does hibernate query not filter the deleted object from the result set anyway?

This question is eligible, as Hibernate does iterate the result-set anyway before returning it to the user.
Hibernate must iterate throug the result-set (except projections and scalar queries) because it tries to match entity objects of the result-set with the ones already present in the persistent context.
This to guarantee:
1. object identity within the persistent context (see http://docs.jboss.org/hibernate/core/4.0/manual/en-US/html/transactions.html#transactions-basics-identity)
2. simulate repeatable-read isolation behavior
(if entity a was already present in your context (=first level cache) with a.name='beta'
then it will remain 'beta' even if the result-set returns the record relative to instance a with name = 'alpha')

It would therefore be a tittle for Hibernate to do also check the state of the matched entity objects in this context.

So why Hibernate query does return objects in deleted state?

I guess the answer is given by following counter-arguments:

1. A query without flush also don't considers new instances (instances created in current transaction),
so why it should indeed recognize deleted instances?

2. Scalar results and projections would return different results than normal queries:



Such discordance would surely create further embarrassments

That's great.

Hi.
First thanks for the answers (I allmost entered flush inside the transaction).
So if i summarize one can not expect a correct result on the following flow :
1.Open UserTransaction.
2.Read List of Elemnts via Hql.
3.Delete one Element.
4.Preform Hql (that should consider the remove value).
5. acoording to 4 value do logic.
6. commit transaction.

Your statement above is not fully correct in this form.
Note that the default behavior in hibernate is FlushMode.AUTO,
so if each query does implicit flushing (as it is by default), the results are correct.

Only when excplicitely disabling flushing, you run into the described problem.