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 flu
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.AbstractFlushingEventListener.flushEverythingToExecutions()
, which ends up (amongst other interesting locations) at flushEntities()
.source.getPersistenceContext().getEntityEntries()
) calling DefaultFlushEntityEventListener.onFlushEntity()
.dirtyCheck()
. That method does make some optimizations wrt to CGLIB dirty flags, but we've still ended up looping over every entity.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
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).
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:
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.