From time to time 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, flush, occurs by default at the following
before some query executions
The SQL statements are issued in the following order
all entity insertions, in the same order the corresponding objects
were saved using
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
(An exception is that objects using
native ID generation are
inserted when they are saved.)
Except when you explicity
flush(), there are absolutely no
guarantees about when the
the JDBC calls, only the order in which they are executed.
However, Hibernate does guarantee that the
will never return stale data; nor will they return the wrong data.
It is possible to change the default behavior so that flush occurs less frequently.
FlushMode class defines three different modes: only flush
at commit time (and only when the Hibernate
is used), flush automatically using the explained routine, or never flush unless
flush() is called explicitly. The last mode is useful for long running
units of work, where a
Session is kept open and disconnected for
a long time (see Section 11.3.2, “Extended session and automatic versioning”).
sess = sf.openSession(); Transaction tx = sess.beginTransaction(); sess.setFlushMode(FlushMode.COMMIT); // allow queries to return stale state Cat izi = (Cat) sess.load(Cat.class, id); izi.setName(iznizi); // might return stale data sess.find("from Cat as cat left outer join cat.kittens kitten"); // change to izi is not flushed! ... tx.commit(); // flush occurs sess.close();
During flush, an exception might occur (e.g. if a DML operation violates a constraint). Since handling exceptions involves some understanding of Hibernate's transactional behavior, we discuss it in Chapter 11, Transactions And Concurrency.