I'm worried that Hibernate won't cause the SQL associated with the session.save(myentity) before executing the HQL queries and updates that depend on the former.
The documentation explains pretty well what causes a flush to occur:
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()
The SQL statements are issued in the
following order:
- all entity insertions in the same order the corresponding objects were
saved using
Session.save()
- all entity updates
- all collection deletions
- all collection element deletions, updates and insertions
- all collection insertions
- all entity deletions in the same order the corresponding objects were
deleted using Session.delete()
An exception is that objects using
native ID generation are inserted when
they are saved.
Except when you explicitly flush()
,
there are absolutely no guarantees
about when the Session executes the
JDBC calls, only the order in which
they are executed. However, Hibernate
does guarantee that the
Query.list(..)
will never return
stale or incorrect data.
I don't know what your function is doing exactly, and in what order, but the documentation is explicit: executing a query will trigger a flush if required. I'm not sure this applies to bulk updates though (why is why I mentioned the order). But why don't you flush after the save if you want to be sure?