Category Archives: Hibernate

The Second Level Cache in Hibernate : Settings and Configurations.

A Hibernate Session is a transaction-level cache of persistent data. We can configure a cluster or JVM-level (SessionFactory-level) cache on a class-by-class and collection-by-collection basis. We can also plug in a clustered cache into Hibernate. At the time of providing cache we need to understand that when we are updating the persistence DB it will not automatically reflect on Cache.

Configuring CACHE in Hibernate

We need to tell Hibernate that which caching implementation we need to  use. This we can accomplish by specifying the name of a class that implements org.hibernate.cache.CacheProvider using the property hibernate.cache.provider_class. Hibernate comes bundled with a number of built-in integrations with open-source cache providers; additionally, we could implement your own and plug it in as outlined above. Prior to 3.2 Hibernate is defaulted to use EhCache as the default cache provider.

To find the CACHE PROVIDERS please check this post <Click Here>

Cache mappings

The <cache> element of a class or collection mapping has the following form:

<cache 
    usage="transactional|read-write|nonstrict-read-write|read-only"  (1)
    region="RegionName"                                              (2)
    include="all|non-lazy"                                           (3)
/>

(1)

usage (required) specifies the caching strategy: transactional, read-write, nonstrict-read-write or read-only

(2)

region (optional, defaults to the class or collection role name) specifies the name of the second level cache region

(3)

include (optional, defaults to all) non-lazy specifies that properties of the entity mapped with lazy="true" may not be cached when attribute-level lazy fetching is enabled

Strategy: read only
  • Useful for data that is read frequently but never updated.
  • It is Simple .
  • Best performer among the all.

If application needs to read but never modify instances of a persistent class, a read-only cache may be used. This is the simplest and best performing strategy. It’s even perfectly safe for use in a cluster.

<class name="eg.Immutable" mutable="false">
    <cache usage="read-only"/>
    ....
</class>
Strategy: read/write
  • Used when our data needs to be updated.
  • It’s having more overhead than read-only caches.
  • When Session.close() or Session.disconnect() is called the transaction should be completed in an environment where JTA is no used.
  • It is never used if serializable transaction isolation level is required.
  • In a JTA environment, for obtaining the JTA TransactionManager we must specify the propertyhibernate.transaction.manager_lookup_class.
  • To use it in a cluster the cache implementation must support locking.

If the application needs to update data, a read-write cache might be appropriate. This cache strategy should never be used if serializable transaction isolation level is required. If the cache is used in a JTA environment, you must specify the property hibernate.transaction.manager_lookup_class, naming a strategy for obtaining the JTA TransactionManager. In other environments, you should ensure that the transaction is completed when Session.close() or Session.disconnect() is called. If you wish to use this strategy in a cluster, you should ensure that the underlying cache implementation supports locking. The built-in cache providers do not.

<class name="eg.Cat" .... >
    <cache usage="read-write"/>
    ....
    <set name="kittens" ... >
        <cache usage="read-write"/>
        ....
    </set>
</class>
 
Strategy: nonstrict read/write
  • Needed if the application needs to update data rarely.
  • we must specify hibernate.transaction.manager_lookup_class to use this in a JTA environment .
  • The transaction is completed when Session.close() or Session.disconnect() is called In other environments (except JTA) .

If the application only occasionally needs to update data (ie. if it is extremely unlikely that two transactions would try to update the same item simultaneously) and strict transaction isolation is not required, a nonstrict-read-write cache might be appropriate. If the cache is used in a JTA environment, you must specify hibernate.transaction.manager_lookup_class. In other environments, you should ensure that the transaction is completed when Session.close() or Session.disconnect() is called.

Strategy: transactional
  • It supports only transactional cache providers such as JBoss TreeCache.
  • only used in JTA environment.

The transactional cache strategy provides support for fully transactional cache providers such as JBoss TreeCache. Such a cache may only be used in a JTA environment and you must specify hibernate.transaction.manager_lookup_class.

Advertisements

List of Cache Providers in Hibernate and their Concurrency Support details

Here in this port you can find the list of Cache providers and their Concurrency support details. (Exerted from Official Hibernate Tutorial)

EHCache (Easy Hibernate Cache)
(org.hibernate.cache.EhCacheProvider)
  • It is fast.
  • lightweight.
  • Easy-to-use.
  • Supports read-only and read/write caching.
  • Supports memory-based and disk-based caching.
  • Does not support clustering.
OSCache (Open Symphony Cache)
(org.hibernate.cache.OSCacheProvider)
  • It is a powerful .
  • flexible package
  • supports read-only and read/write caching.
  • Supports memory- based and disk-based caching.
  • Provides basic support for clustering via either JavaGroups or JMS.
SwarmCache (org.hibernate.cache.SwarmCacheProvider)
  • is a cluster-based caching.
  • supports read-only or nonstrict read/write caching .
  • appropriate for applications those have more read operations than write operations.
JBoss TreeCache (org.hibernate.cache.TreeCacheProvider)
  • is a powerful replicated and transactional cache.
  • useful when we need a true transaction-capable caching architecture .

Cache providers.

Cache

Provider class

Type

Cluster Safe

Query Cache Supported

Hashtable (not intended for production use)

org.hibernate.cache.

HashtableCache

Provider

memory

  yes

EHCache

org.hibernate.cache.

EhCacheProvider

memory, disk

  yes
OSCache

org.hibernate.cache.

OSCacheProvider

memory, disk

  yes

SwarmCache

org.hibernate.cache.

SwarmCacheProvider

clustered (ip multicast)

yes (clustered invalidation)

yes (clock sync req.)

JBoss Cache 1.x

org.hibernate.cache.

TreeCacheProvider

clustered (ip multicast), transactional

yes (replication)

yes (clock sync req.)

JBoss Cache 2

org.hibernate.cache.

jbc2.JBossCache

RegionFactory

clustered (ip multicast), transactional

yes (replication or invalidation)

yes (clock sync req.)

Cache Concurrency Strategy Support

Cache

read-only

nonstrict-read-write

read-write

transactional

Hashtable (not intended for production use)

yes

yes

yes

 

EHCache

yes

yes

yes

 

OSCache

yes

yes

yes

 

SwarmCache

yes

yes

   

JBoss Cache 1.x

yes

   

yes

JBoss Cache 2

yes

   

yes

Hibernate generator classes

Extracted from Hibernate online official tutorials

In Hibernate the optional <generator> child element names a Java class used to generate unique identifiers for instances of the persistent class.

If any parameters are required to configure or initialize the generator instance, they are passed using the <param> element.

<id name="id" type="long" column="cat_id">
        <generator class="org.hibernate.id.TableHiLoGenerator">
                <param name="table">uid_table</param>
                <param name="column">next_hi_value_column</param>
        </generator>
</id>

All generators implement the interface org.hibernate.id.IdentifierGenerator. This is a very simple interface; some applications may choose to provide their own specialized implementations. However, Hibernate provides a range of built-in implementations. There are shortcut names for the built-in generators:

increment

generates identifiers of type long, short or int that are unique only when no other process is inserting data into the same table. Do not use in a cluster.

identity

supports identity columns in DB2, MySQL, MS SQL Server, Sybase and HypersonicSQL. The returned identifier is of type long, short or int.

sequence

uses a sequence in DB2, PostgreSQL, Oracle, SAP DB, McKoi or a generator in Interbase. The returned identifier is of type long, short or int

hilo

uses a hi/lo algorithm to efficiently generate identifiers of type long, short or int, given a table and column (by default hibernate_unique_key and next_hi respectively) as a source of hi values. The hi/lo algorithm generates identifiers that are unique only for a particular database.

seqhilo

uses a hi/lo algorithm to efficiently generate identifiers of type long, short or int, given a named database sequence.

uuid

uses a 128-bit UUID algorithm to generate identifiers of type string, unique within a network (the IP address is used). The UUID is encoded as a string of hexadecimal digits of length 32.

guid

uses a database-generated GUID string on MS SQL Server and MySQL.

native

picks identity, sequence or hilo depending upon the capabilities of the underlying database.

assigned

lets the application to assign an identifier to the object before save() is called. This is the default strategy if no <generator> element is specified.

select

retrieves a primary key assigned by a database trigger by selecting the row by some unique key and retrieving the primary key value.

foreign

uses the identifier of another associated object. Usually used in conjunction with a <one-to-one> primary key association.

sequence-identity

a specialized sequence generation strategy which utilizes a database sequence for the actual value generation, but combines this with JDBC3 getGeneratedKeys to actually return the generated identifier value as part of the insert statement execution. This strategy is only known to be supported on Oracle 10g drivers targetted for JDK 1.4. Note comments on these insert statements are disabled due to a bug in the Oracle drivers.

Advantages of Hibernate

  • Caching objects. The session is a transaction-level cache of persistent objects. You may also enable a JVM-level/cluster cache to memory and/or local disk.
  • Executing SQL statements later, when needed. The session never issues an INSERT or UPDATE until it is actually needed. So if an exception occurs and you need to abort the transaction, some statements will never actually be issued. Furthermore, this keeps lock times in the database as short as possible (from the late UPDATE to the transaction end).
  • Never updating unmodified objects. It is very common in hand-coded JDBC to see the persistent state of an object updated, just in case it changed…..for example, the user pressed the save button but may not have edited any fields. Hibernate always knows if an object’s state actually changed, as long as you are inside the same (possibly very long) unit of work.
  • Efficient Collection Handling. Likewise, Hibernate only ever inserts/updates/deletes collection rows that actually changed.
  • Rolling two updates into one. As a corollary to (1) and (3), Hibernate can roll two seemingly unrelated updates of the same object into one UPDATE statement.
  • Updating only the modified columns. Hibernate knows exactly which columns need updating and, if you choose, will update only those columns.
  • Outer join fetching. Hibernate implements a very efficient outer-join fetching algorithm! In addition, you can use subselect and batch pre-fetch optimizations.
  • Lazy collection initialization.
  • Lazy object initialization. Hibernate can use runtime-generated proxies (CGLIB) or interception injected through bytecode instrumentation at build-time.

A few more (optional) features of Hibernate that your handcoded JDBC may or may not currently benefit from

  • second-level caching of arbitrary query results, from HQL, Criteria, and even native SQL queries
  • efficient ‘PreparedStatement’ caching (Hibernate always uses ‘PreparedStatement’ for calls to the database)
  • JDBC 2 style batch updates
  • Pluggable connection pooling

For more information please follow this link Click here

Technorati Tags: ,

Test your Spring – Hibernate Applications using Unitils

Unitils is an open source library aimed at making unit testing easy and maintainable. Unitils builds further on existing libraries like DBUnit and EasyMock and integrates with JUnit and TestNG. This article will help you to test Spring- hibernate applications easily using unitles.

Technorati: spring, hibernate, unitils

UML models of open source projects

This site includes the UML models of some great open source projects like JBoss, Spring, Hibernate etc. Its really helping me to understand this frameworks.,


Technorati : , , , , ,

Hibernate – Difference between session’s get() and load()

Today I went through a great post by Mr. Ganeshji Marwah which will be very useful to beginners. This post is regarding with the difference between Hibernate session’s get() and load() methods. As he describes it is very helpful to improve the performance level. Please click here to visit this post.

Technorati tags: Hibernate