Hibernate uses three different caches for objects to reduce SQL calls:

1. First-level cache - Session on a per-transactinal basis. That is to say, if an object is modified several times within the same transaction, Hibernate will generate only one SQL UPDATE at the end of tx.
2. Second-level cache - Session Factory (cache available between transactions - cluster or JVM level).
3. Query-level cache - Cache actual result rather than just persistent objects.

Caching Concurrency Strategy
There are four caching concurrency strategies are available:

1. Read-only: This strategy is useful for data that is read frequently but never updated. This is by far the simplest and best-performing cache strategy.
2. Read/write: Read/write caches may be appropriate if your data needs to be updated. They carry more overhead than read-only caches. In non-JTA environments, each transaction should be completed when Session.close() or Session.disconnect() is called.
3. Nonstrict read/write: This strategy does not guarantee that two transactions won’t simultaneously modify the same data. Therefore, it may be most appropriate for data that is read often but only occasionally modified.
4. Transactional: This is a fully transactional cache that may be used only in a JTA environment.

Caching Cluster Support 

Apart from caching strategy, we can also evaluate the cache implementatin in term of cluster support. Only SwarmCache and JBoss TreeCache have cluster support. They achieve this via IP multicasting. To ensure cluster safety, SwarmCache uses clustered invalidation whereas JBoss TreeCache uses replication.

Example of usage

1. Country: Airport (1:M) : Country has a set of Aiports.
2. Employee: Language (M:M) : Employee can speak a set of Languages and a Language can be spoken by many different Employees.
3. Country: Employee (1:M) - a Country has many Employee.

Relationship Modeling

In relational model, 1-M relationship is modeled by “M” side has FK to “1″ side and “1″ side doesn’t even know “M” side exists. Only the time you delete a row in ”1″ side and “delete-cascade” is turned on, it will take care the rows from “M” side referencing it. However, on the contrary, you will see the “1″ side referencing “M” via collection class like Set and “M” may or may not have reference back to “1″ side in object model (depends on whether you want bidirectional navigation).

On the other hand, M:M relationship is modeled using Join-Table in relational model. Both M sides will not have knowledge on the relationships because this knowledge is solely kept in the Join-Table. However, M:M in object model, the knowledge can be kept in one side of “M” or both.

The main cause of the difference in relational and object model is due to there is limitation in table structure to reference the non-fixed “M” side. Even you may try to use more than one column to simulate that. You don’t know how many columns to use. But in object world, you don’t have this limitation in object reference.

<hibernate-mapping package=”com.wakaleo.articles.caching.businessobjects”>

    <class name=”Employee” table=”EMPLOYEE” dynamic-update=”true”>
  <meta attribute=”implement-equals”>true</meta>   
  <cache usage=”read-write”/>
  
        <id name=”id” type=”long” unsaved-value=”null” >
            <column name=”emp_id” not-null=”true”/>
            <generator class=”increment”/>
        </id>

    <property column=”emp_surname” name=”surname” type=”string”/>
    <property column=”emp_firstname” name=”firstname” type=”string”/>
   
    <many-to-one name=”country”
            column=”cn_id”
            class=”com.wakaleo.articles.caching.businessobjects.Country” 
           not-null=”true” />
      
  <!– Lazy-loading is disactivated to demonstrate caching behavior –>   
     <set name=”languages” table=”EMPLOYEE_SPEAKS_LANGUAGE” lazy=”false”>
       <cache usage=”read-write”/>
         <key column=”emp_id”/>
          <many-to-many column=”lan_id” class=”Language”/>
     </set>                 
    </class>
</hibernate-mapping>

• hibernate.cfg.xml - Hibernate configuration like cache-level, show sql and mapping files.

<hibernate-configuration>
…
   <property name=”hibernate.cache.use_query_cache”>true</property>
   <property name=”hibernate.cache.use_second_level_cache”>
         false
   </property>
   <property name=”hibernate.cache.provider_class”>
        org.hibernate.cache.EhCacheProvider
   </property>
</hibernate-configuration>

• DAO for searching

How the cache work

Hibernate doesn’t not cache the object reference but the primitive properties of an object. So, the associations are not cached by default because of it. But you can tell which association you want to cache in the mapping file.