Posted on 2008-11-01 10:11
Neil's NoteBook 阅读(115)
评论(0) 编辑 收藏
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 points
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 explicity 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 data; nor will they return the wrong data.
It is possible to change the default behavior so that flush occurs less
frequently. The FlushMode
class defines three
different modes: only flush at commit time (and only when the Hibernate Transaction
API 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.