Hibernate’s Smart Automatic Dirty Check

I am one lucky guy. As an instructor, my job begins anew each week. Each week, I face a new group of people trying to learn a technology or skill. People have asked "don't you get bored teaching." How could I? Each week the topic changes and the needs of my students change. And when I am not teaching, I am working to understand new technologies and how/when to put it into courseware.

But perhaps what makes my job the most enjoyable is when I have a group of students that are really engaging and come up with questions that make me stop and think. In other words, they challenge me to improve my own skills/knowledge on a topic that I think I already know pretty well. This week, I was teaching Hibernate and had just one of those questions from one of my students, Josephine.

We were exploring Hibernate's automatic dirty checking. As those familiar with Hibernate have learned, Hibernate knows persistent objects and tracks state change to those objects. No explicit call to save (or update) a persistent object is necessary. Just committing the transaction causes the new state of a persistent object to be synchronized to the database. However, Josephine asked what would happen if the state of an object was changed and then changed back again to the original state in the same transaction? Would Hibernate know that no real change occurred and therefore avoid an SQL call to the database? What's your guess? In fact, the answer surprised me when I tested it out.

To describe the situation with a little more detail, explore the following persistent class and Hibernate mapping file. Nothing real complex about the Contact class or its mapping to a Contact table.

public class Contact {
 private Long id = 0L;
 private String firstName;
 private String lastName;
 private Date dateOfBirth;
 private boolean married = false;
 private int children;
 private int age;
 //getters and setters and constructors
}

<hibernate-mapping package="com.intertech.domain">
  <class name="Contact">
    <id name="id">
      <generator class="increment" />
    </id>
    <property name="firstName" column="first_name" not-null="true" />
    <property name="lastName" column="last_name" not-null="true" />
    <property name="dateOfBirth" column="date_of_birth" type="date" not-null="true" />
    <property name="married" />
    <property name="children" />
    <property name="age" formula="datediff('yy', date_of_birth, curdate())" access="field"/>
  </class>
</hibernate-mapping>

Now check out this little bit of test code. In this example, the Contact with an ID of 2 (2 long) has 4 children.

SessionFactory sf = new Configuration().configure().buildSessionFactory();
Session s = sf.openSession();
Transaction t = s.beginTransaction();
Contact c = (Contact) s.load(com.intertech.domain.Contact.class, 2L);
c.setChildren(32);
c.setChildren(4);
t.commit();
s.close();

So, what happens if code updates the number of children to another number (in this case 32) and then returning it to 4? Take a look at the log output (with hibernate.show_sql=true). The answer surprised me!

Hibernate:
     select
        contact0_.id as id0_0_,
        contact0_.first_name as first2_0_0_,
        contact0_.last_name as last3_0_0_,
        contact0_.date_of_birth as date4_0_0_,
        contact0_.married as married0_0_,
        contact0_.children as children0_0_,
        datediff('yy',contact0_.date_of_birth,curdate()) as formula0_0_     from
        Contact contact0_
     where
        contact0_.id=?

The SQL select is made to load to the Contact, but no update SQL is issued. Hibernate actually checks to see if the state has undergone real modification before issuing an SQL to synchronize the state with the database. Another case of the students teaching the instructor.

Come join me in learning Hibernate in Intertech's Complete Hibernate class. We offer both live and virtual training, and while I may not have all the answers, I'll work hard to find them for you! That's one of the best parts of my job!