Five ‘s Weblog

November 11, 2007

The process-level cache in Hibernate

Filed under: ORM — by powerdream5 @ 8:03 pm
Tags: , ,

11_11_1_2007.jpg

        Hibernate has two kinds of cache, which are the first-level cache and the second-level cache. We also call the first-leve cache session cache, and the second-level cache process-level cache. The first-level cache is mandatory and can’t be turned off; However, the second-level cache in Hibernate is optional. Because the process-level cache caches objects across sessions and has process or cluster scope, in some situation, turning on the process-level cache can improve the performance of the application. In fact, before accessing the database to load an object, Hibernate will first look in the Session cache and then in the process-level cache.

       The process-level cache is best used to store objects that change relatively infrequently, and it is set up in two steps. First, you have to decide which concurrency strategy to use. After that, you configure cache expiration and physical cache attribtes using the cache provider. Hibernate supports a variety of caching strategies including:
read-only : which is suitable for objects which never changes. Use if for reference data only.
read-write : which is suitable for objects that are modified by the application.

      To cache these classes in the process-level cache, we must use the <cache> element in the O/R mapping. For example:
<class name=”?” talbe=”?”>
      <cache usage=”read-wirte” />
      …
</class>

      The usage=”read-write” attribute specifies that instances of this class are sometimes updated by the application. One thing needed to remember is that you must enable lazy loading for relationships that are from objects that not cached to objects that are cached to ensure that the applications uses the cache.
<class name=”?” talbe=”?”>
      <cache usage=”read-wirte” />
       …

       <set name=”?” lazy=”true”>
                /*collections require their own <cache> element*/
               <cache usage=”read-only” />
                …
        </set>
</class>

11_11_2_2007.jpg

November 9, 2007

Eager loading in Hibernate

Filed under: ORM — by powerdream5 @ 5:50 pm
Tags: , , ,

      In default, Hibernate adopts the mechanism of lazy loading to load objects from databases. Lazy loading contributes a lot to improve the performance of an application by limiting the amount of objects that will be needed. In contrast to lazy loading, eager loading loads the full objects tree once. Because eager loads multiple related objects with a single SELECT statement instead of using multiple SELECT statements, therefore in some situations, eager loads can also improve the performance of the application by reducing the times of accessing the database.

     There are two ways to configure eager loading in Hibernate. They are staticly eager loading and dynamically eager loading respectively. If the application always traverses a relationship, you might want to configure it to be always staticly eager loaded. Conversely, you might want to dynamically configure eager loading for relationships that are only traversed by the application when handling particular requests.

     One way to configure static eager loading is specifying a value for the fetch attribute of the relationship’s mapping element. 
     This attribute can have one of two values:
     select: Lazily load the referenced object or collection with a separate SQL SELECT statement. It is the default value
     join: Eagerly load the referenced object or collection using an outer join

<hibernate-mapping>
     <class name=”?” table=”?”>
          <many-to-one name=”?” fetch=”join” column=”?” />
     </class>
</hibernate-mapping>

      To configure dynamical eager loading, you must use queries with fetch joins.
<hibernate-mapping>
      …
      <query name=”queryName”>
            <![CDATA[
                 from student s
                 left outer join fetch s.classID as c
                 left outer join fetch c.className
                 where s.id = ?
            ]]>
       </query>
     ….
</hibernate-mapping>

     Finally, take a note that Hibernate has a rule that a class can only have at most one collection loaded using an outer join. This is to prevent inefficient queries that return the Cartesian product of too large collections.

11_9_2_2007.jpg

October 18, 2007

uni-directional or bidirectional ?

Filed under: ORM — by powerdream5 @ 10:52 pm
Tags: , , , ,

        When mapping the domain model to the database schema,  perhaps we often ask ourselves one question: Making a one-to-many relationship uni-directional or making it bidirectional, which is better in performance. Today, I am going to show an example to demonstrate the difference between uni-direction and bidirection. I am using Hibernate framework.

        There is a class named Consumer and a class named CreditAccount, both of which mapped to the consumer and credit_account table respectively. It is obvious that each Consumer has more than one credit account, therefore, the relationship between the two classes is one-to-many. Firstly, I make the relationship uni-directional.

10_18_2_2007.jpg 

the mapping files are listed in the following:

//Consumer.hbm.xml
<hibernate-mapping>
          <class name=”Consumer” table=”consumer”>
                 <id name=”id” column=”CONSUMER_ID”>
                       <generator class=”native” />
                </id>
               <property name=”firstName” type=”string” column=”FIRSTNAME”/>
               <property name=”lastName” type=”string” column=”LASTNAME”/>
               <set name=”creditAccount” table=”credit_account” cascade=”all”>
                      <key column=”CONSUMER_ID”/>
                      <one-to-many class=”CreditAccount” />
              </set>
           </class>
</hibernate-mapping>

//CreditAccount.hbm.xml
<hibernate-mapping>
          <class name=”CreditAccount” table=”credit_account”>
                 <id name=”id” column=”ACCOUNT_ID”>
                         <generator class=”native” />
                 </id>
                 <property name=”accountNumber” type=”string” column=”ACCOUNT_NUMBER”/>
          </class>
</hibernate-mapping>

We try to insert an new account into the database, from the comman window or log files, we can see that two sql setences are executed. There are:
insert into credit_account(ACCOUNT_NUMBER) values(?)
update credit_account set CONSUMER_ID=? where ACCOUNT_ID=?

Now, I am going to make a little change to the CreditAccount class to make the relationship between Consumer and it bidirectional.  Therefore, I also need to change the mapping files. After being changed, they should be:

//Consumer.hbm.xml
<hibernate-mapping>
          <class name=”Consumer” table=”consumer”>
                 <id name=”id” column=”CONSUMER_ID”>
                       <generator class=”native” />
                </id>
               <property name=”firstName” type=”string” column=”FIRSTNAME”/>
               <property name=”lastName” type=”string” column=”LASTNAME”/>

               //make sure to set “inverse=true”
               <set name=”creditAccount” table=”credit_account” cascade=”all” inverse=”true”>
                      <key column=”CONSUMER_ID”/>
                      <one-to-many class=”CreditAccount” />
              </set>
           </class>
</hibernate-mapping>

//CreditAccount.hbm.xml
<hibernate-mapping>
          <class name=”CreditAccount” table=”credit_account”>
                 <id name=”id” column=”ACCOUNT_ID”>
                         <generator class=”native” />
                 </id>
                 <property name=”accountNumber” type=”string” column=”ACCOUNT_NUMBER”/>
                 <many-to-one name=”consumer” class=”Consumer” column=”CONSUMER_ID”>
          </class>
</hibernate-mapping>

Now, if we insert a new account into the database, only one sql sentence will be executed:
insert into credit_account(ACCOUNT_NUMBER,CONSUMER_ID) values(?, ?)

       There is no doubt that bidirection is better than uni-direction in the performance. If the relationship is uni-direction, only one end is going to maintain their relationshop. The other end cannot see any change of the relationship.  Therefore, the first time we need to execute two sql sentences, the first sql sentence inserts the data into the credit_account table (at this time, the system doesn’t know this account belongs to whom), and the second sql help the credit_account table build its relationship with the consumer table. However, both the end of the bidirectional relationship are aware of any changes, therefore, only one sql sentence can finish two tasks: inserting data and mataining the relationship.

        You can download the source files.

10_18_1_2007.jpg

Blog at WordPress.com.