Hibernate Cascading on flushing

this snapshot (taken with YourKit profiler) shows the tremendous performance impact of cascading the flush to dependent objects - even if nothing has to be written to the DB.

Basically if you have
Employee {
String name;
Company company;
}

and you update/flush Employee, the blessed hibernate will try to flush also Company; And if Company contains other dependent objects, the process will go on forever and eat all your CPU.

CascadeType should be NONE by default.

As you can see here
http://www.docjar.com/docs/api/org/hibernate/event/def/AbstractFlushingEventListener.html

there are quite a lot of operations involved when persisting stuff.


So the message is: avoid as much as you can doing "find" operation in a transaction where you do updates (this will autoflush at every find). Also avoid cascading operations on dependent objects.

hibernate DefaultAutoFlushEventListener.onAutoFlush

this explains very well

http://blog.xebia.com/2008/07/18/configuring-hibernate-and-spring-for-jta/

and

"The Session is sometimes flushed before query execution in order to ensure that queries never return stale state. This is the default flush mode. "


using FlushModeType.COMMIT
http://download.oracle.com/javaee/5/api/javax/persistence/EntityManager.html#setFlushMode%28javax.persistence.FlushModeType%29

improves a LOT performance, because flushing is an expensive operation.
But the result can be undetermined, and in fact my application now breaks because "find" queries don't find non-flushed entities:

see here

"If FlushModeType.COMMIT is set, the effect of updates made to entities in the persistence context upon queries is unspecified. "

:o))) I love working with unspecified products! Such a thrill!
These APIs were designed by lawyers.


Here it says explicitely:

Set flushes to occur at commit or before query execution. If
the flush mode is set to FlushModeType.COMMIT, changes
made during the transaction might not be visible in the
query execution results.