Logic in ParentA is such that if there’s a key existing the value should be updated. Else the new Child object is persisted. We retry on StaleObjectState by restarting the session, and reloading the objects. So when trying in my dev. environmnet I process the same ParentA object across multiple threads. Processing of ThreadA inserts ChildA1, processing of ThreadB throws StaleObject during flush. Retry logic appropriately updates the ChildA to value2.
But in our production environment ThreadB creates the new ChildA1 object (thus resulting in duplicates). Logs do indicate a StaleObject state. Despite the exception the child object is persisted. Is that related?

I had to use a stored procedure to read data from a database. Some of the fields are of fixed length of type CHAR. Some of the data in these fields were padded with spaces to fill their fixed lengths. I have an object that is mapped to these fields, each property being of type String. For each setter, I was using the trim method to remove the padding from the input field. Using the trim method caused the object to be marked as dirty, thus causing an unwanted update. Really odd at first since there is no corresponding table to update to.

A nice workaround that is available if you also use Spring and annotation-driven transactions is to declare your read-only service calls to be just that. This will flush out any writethroughs early on. The resulting code will look something like

@Transactional(readOnly=true) public void serviceCall(…)

which I also find to be concise and readable.

The org.hibernate.event.def.DefaultFlushEntityEventListener.dirtyCheck(FlushEntityEvent) method has a line, that reads:
cannotDirtyCheck = loadedState==null;
(It is amazing what reading code can teach you sometimes…)

Now when you reattach an object, the object is not loaded from the database and Hibernate has no way of knowing whether it has changed in the meantime or not (other then querying the database, which you can configure it to do). There are several ways to reattach: using .update() or .lock() or cascading any of these methods. If you .update(), obviously Hibernate will update the database. If you lock, it depends on your LockMode.

I don’t know what you mean by “loaded state”, but whatever it is you are wrong saying that dirty checking doesn’t work when entity is reattached. It works, otherwise use of this feature would be very limited.

True. True.