Make Hibernate Update/Create Changed Objects

Make Hibernate Update/Create Changed Objects

While Hibernate is a mature framework it still has a a lot of room for improvement. Starting from polishing documentation: e.g. “MappingException JavaDoc: An exception that usually occurs at configuration time, rather than runtime, as a result of something screwy in the O-R mappings.“, and going towards more powerful default optimization.

In fact, Rod Johnson (leader of Spring Framework’s parenthood gang :)), and other SpringSource consultants, constantly mention that most of their time, on projects that use Hibernate, is spent fixing Hibernate optimization bugs.

A lot of people form their opinions on what characteristics of “a good software framework” are. There are books, articles about it, but people are different, so opinions vary. One of the characteristics that makes a good framework, in my opinion is “while allowing clients to hook into the internal framework code, do not encourage it”. Meaning the flexibility is there, but the framework should not encourage its clients to get inside framework’s stereotypes. This way framework’s code (internal stereotypes) can alter, and still have “older version clients” running without (significant) change.

One of such hooks that Hibernate actually encourages to use is evicting the object from the session.

Here is an example:

While reviewing one of a Spring Batch jobs, I found that under the same “transaction management roof” (HibernateTransactionManager) jdbcTemplate and hibernateTemplate behaved differently: jdbcTemplate updated records in DB, but hibernateTemplate was not even trying.

So I enabled Hibernate logging in “”:

log4j.rootLogger = ERROR, errorsLog
# Hibernate logs = DEBUG, hibernateLog = false
log4j.appender.hibernateLog = org.apache.log4j.RollingFileAppender
log4j.appender.hibernateLog.File = ./path-to/hibernate.log
# Set the maximum log file size (use KB, MB or GB)
log4j.appender.hibernateLog.MaxFileSize = 4096KB
# Set the number of log files (0 means no backup files at all)
log4j.appender.hibernateLog.MaxBackupIndex = 10
# Append to the end of the file or overwrites the file at start.
log4j.appender.hibernateLog.Append = false
log4j.appender.hibernateLog.layout = org.apache.log4j.PatternLayout
log4j.appender.hibernateLog.layout.ConversionPattern = [%p] [%d{yyyy-MM-dd @ HH:mm:ss}] [%t|%c{1}] %m%n
log4j.appender.errorsLog = org.apache.log4j.RollingFileAppender
log4j.appender.errorsLog.File = ./path-to/hibernate-error.log
log4j.appender.errorsLog.MaxFileSize = 4096KB
log4j.appender.errorsLog.MaxBackupIndex = 1
log4j.appender.errorsLog.layout = org.apache.log4j.PatternLayout
log4j.appender.errorsLog.layout.ConversionPattern = [%p] [%d{yyyy-MM-dd @ HH:mm:ss}] [%t|%c{1}] %m%n

First, I read an object via Hibernate, update it in the code, and then call a dao’s update method to persist it – pretty simple. However while debugging it step by step, after executing the Hibernate update query, in a log, I saw:

[DEBUG] [main|DefaultSaveOrUpdateEventListener] ignoring persistent instance
[DEBUG] [main|DefaultSaveOrUpdateEventListener] object already associated with session: [EntityName#3]

So the Hibernate did not update the object due the fact that it thought that another object was already associated with this Hibernate session. Which, in fact, was the same reference to the same object, only the update was called from a different instance.

The solution to this was to evict the object from the Hibernate session right after reading it:

  ObjectDto objectDto = dao.findById( id );
  dao.getHibernateTemplate().evict( objectDto )

Once the fix was applied, after Hibernate update call, I saw:

[DEBUG] [main|DefaultEvictEventListener] evicting [EntityName]
[DEBUG] [main|DefaultSaveOrUpdateEventListener] updating detached instance
[DEBUG] [main|DefaultSaveOrUpdateEventListener] updating [EntityName#3]
[DEBUG] [main|DefaultSaveOrUpdateEventListener] updating [EntityName#3]

And the object was successfully persisted into the database.

Happy ORMing!


  1. That’s interesting behavior, I’m curious what was being used in this job as an ItemReader? By default, the HibernateCursorItemReader uses a Stateless session, to avoid these kinds of problems, was this turned off? (which is an option) Or was the JPA paging reader used?

  2. @Lucas,

    This is more of a Hibernate rant, and is not in any way a Spring Batch specific problem, and yes, you’re right – HibernateCursorItemReader does use a stateless session by default.

    In that particular job, however, a custom reader was used that had a session injected from an application dao layer.

    – Toly

  3. David Wine Gifts

    Please explain what are the changes do i need to implement if I use Hibernate with Spring for the same question..

  4. @David,

    As you see eviction happens on a HibernateTemplate:

    dao.getHibernateTemplate().evict( objectDto )

    which is in fact a Spring Object.

    – Toly

tell me something...
  1. (required)
  2. (valid email - optional)
  3. Captcha
  4. (required)