When Hibernate flushes a Session, how does it decide which objects in the session are dirty?

Question

My understanding of Hibernate is that as objects are loaded from the DB they are added to the Session. At various points, depending on your configuration, the session is flushed. At this point, modified objects are written to the database.

How does Hibernate decide which objects are 'dirty' and need to be written?

Do the proxies generated by Hibernate intercept assignments to fields, and add the object to a dirty list in the Session?

Or does Hibernate look at each object in the Session and compare it with the objects original state?

Or something completely different?

Answer 1

Hibernate does/can use bytecode generation (CGLIB) so that it knows a field is dirty as soon as you call the setter (or even assign to the field afaict).

This immediately marks that field/object as dirty, but doesn't reduce the number of objects that need to be dirty-checked during flush. All it does is impact the implementation of org.hibernate.engine.EntityEntry.requiresDirtyCheck(). It still does a field-by-field comparison to check for dirtiness.

I say the above based on a recent trawl through the source code (3.2.6GA), with whatever credibility that adds. Points of interest are:

• SessionImpl.flush() triggers an onFlush() event.
• SessionImpl.list() calls autoFlushIfRequired() which triggers an onAutoFlush() event. (on the tables-of-interest). That is, queries can invoke a flush. Interestingly, no flush occurs if there is no transaction.
• Both those events eventually end up in AbstractFlushingEventListener.flushEverythingToExecutions(), which ends up (amongst other interesting locations) at flushEntities().
• That loops over every entity in the session (source.getPersistenceContext().getEntityEntries()) calling DefaultFlushEntityEventListener.onFlushEntity().
• You eventually end up at dirtyCheck(). That method does make some optimizations wrt to CGLIB dirty flags, but we've still ended up looping over every entity.

Answer 2

Hibernate takes a snapshot of the state of each object that gets loaded into the Session. On flush, each object in the Session is compared with its corresponding snapshot to determine which ones are dirty. SQL statements are issued as required, and the snapshots are updated to reflect the state of the (now clean) Session objects.

Answer 3

Take a look to org.hibernate.event.def.DefaultFlushEntityEventListener.dirtyCheck Every element in the session goes to this method to determine if it is dirty or not by comparing with an untouched version (one from the cache or one from the database).

Answer 4

Hibernate default dirty checking mechanism will traverse current attached entities and match all properties against their initial loading-time values.

You can better visualize this process in the following diagram:

Answer 5

These answers are incomplete (at best -- I am not an expert here). If you have an hib man entity in your session, you do NOTHING to it, you can still get an update issued when you call save() on it. when? when another session updates that object between your load() and save(). here is my example of this: hibernate sets dirty flag (and issues update) even though client did not change value