SQL Zone is brought to you in partnership with:

I’m a software engineer with a passion for REST, TDD and clean code, Web Security and Data Mining. Baeldung is about all of these and more. Eugen is a DZone MVB and is not an employee of DZone and has posted 20 posts at DZone. You can read more from them at their website. View Full User Profile

The Persistence Layer with Spring 3 and Hibernate 4

  • submit to reddit

This is the first of a series of articles about Persistence with Spring. This article will focus on the configuration and implementation of the persistence layer with Spring 3.1 and Hibernate. For a step by step introduction about setting up the Spring context using Java based configuration and the basic Maven pom for the project, see this.

The Persistence with Spring series:

No More Spring Templates

Starting Spring 3.0 and Hibernate 3.0.1, managing the Hibernate Session with Springs HibernateTemplate is no longer necessary. It is now possible to make use of contextual sessions – sessions managed directly by Hibernate and kept active throughout the scope of a transaction.

As a consequence, it is now best practice to use the Hibernate API directly instead of the HibernateTemplate, which will effectively decouple the DAO layer implementation from Spring entirely.

Exception Translation without the template

One of the responsibilities of HibernateTemplate is exception translation – translating the low level Hibernate exceptions – which tie the API to Hibernate as the single possible ORM – into higher level, generic Spring exceptions.

Without the template to do that, exception translation can still be enabled by annotating the DAOs with the @Repository annotation. That, coupled with a Spring bean postprocessor will advice all @Repository beans with all the implementations of PersistenceExceptionTranslator found in the Spring context – to provide exception translation without using the template.

Exception translation is done through proxies; in order for Spring to be able to create proxies around the DAO classes, these must not be declared final.

Hibernate Session management without the template

When Hibernate support for contextual sessions came out, the HibernateTemplate essentially became obsolete; in fact, the javadoc of the class has been updated with this advice (bold from the original):

NOTE: As of Hibernate 3.0.1, transactional Hibernate access code can also be coded in plain Hibernate style. Hence, for newly started projects, consider adopting the standard Hibernate3 style of coding data access objects instead, based on {@link org.hibernate.SessionFactory#getCurrentSession()}.

The Spring Java configuration

The Hibernate SessionFactory is set up in the configuration by creating a Spring factory bean to manage it – the AnnotationSessionFactoryBean; this will enable autodetection of the entity classes by classpath scanning. Note that this requires Hibernate 3.2+ and JDK 1.5+.

The alternative is to manually specify all the annotated entity classes to the session factory bean, by using the setAnnotatedClasses method.

public class PersistenceHibernateConfig{
   public AnnotationSessionFactoryBean alertsSessionFactory(){
      AnnotationSessionFactoryBean sessionFactory = new AnnotationSessionFactoryBean();
      sessionFactory.setDataSource( this.restDataSource() );
      sessionFactory.setPackagesToScan( new String[ ] { "org.rest" } );
      sessionFactory.setHibernateProperties( this.hibernateProperties() );
      return sessionFactory;
   public DataSource restDataSource(){
      DriverManagerDataSource dataSource = new DriverManagerDataSource();
      dataSource.setDriverClassName( this.driverClassName );
      dataSource.setUrl( this.url );
      dataSource.setUsername( "restUser" );
      dataSource.setPassword( "restmy5ql" );
      return dataSource;
   public HibernateTransactionManager transactionManager(){
      HibernateTransactionManager txManager = new HibernateTransactionManager();
      txManager.setSessionFactory( this.alertsSessionFactory().getObject() );
      return txManager;
   public PersistenceExceptionTranslationPostProcessor exceptionTranslation(){
      return new PersistenceExceptionTranslationPostProcessor();


Also, note that cglib must be on the classpath for Java @Configuration classes to work; to better understand the need for cglib as a dependency, see this article.

The Spring XML configuration

The same Spring configuration with XML:

<bean id="sessionFactory" class=
   <property name="dataSource" ref="dataSource" />
   <property name="packagesToScan" value="org.rest" />
   <property name="hibernateProperties">
<bean id="dataSource" class=
   <property name="driverClassName" value="${driverClassName}" />
   <property name="url" value="${url}" />
   <property name="username" value="restUser" />
   <property name="password" value="restmy5ql" />

<bean id="txManager" class=
   <property name="sessionFactory" ref="sessionFactory" />
<tx:annotation-driven transaction-manager="txManager" />

There is a relatively small difference between the way Spring is configured in XML and the new Java based configuration – in XML, a reference to another bean can point to either the bean or a bean factory for that bean. In Java however, the compiler wouldn’t allow that, and so the SessionFactory is first retrieved from it’s factory and then passed to the transaction manager:

transactionManager.setSessionFactory( this.alertsSessionFactory().getObject() );

The Hibernate Properties

Hibernate is configured to work with Spring by using the following Hibernate properties:


Note that the MySQL dialect is included as a reference, but any Hibernate supported dialect will do.

Potential for Exceptions

The Transaction Factory

The Hibernate contract for creating transactions is specified by the TransactionFactory interface. In order for Spring to fully manage transactions, the default implementation of this contract – JDBCTransactionFactory – is replaced by default with it’s Spring-aware counterpart – SpringTransactionFactory.

This can also be done manually, in the Hibernate properties (it is however redundant):


The Current Session Context

When the Hibernate SessionFactory is created in the Spring context by it’s factory bean, it will create the CurrentSessionContext. This is the contract for supporting the current session concept and its implementation is decided by analyzing the “hibernate.current_session_context_class” Hibernate property.

Setting this property to “managed” means using the managed implementation for contextual sessions – ManagedSessionContext – which assumes that the current session is managed by an external entity. In our Spring context, that would fail with:

org.springframework.orm.hibernate3.HibernateSystemException: No session currently bound to execution context

Setting the property to “thread” would enable the thread-bound strategy in the Hibernate configuration; this would also conflict with Spring Transaction management and would result in:

org.springframework.orm.hibernate3.HibernateSystemException: persist is not valid without active transaction

To let Spring manage transactions, this property needs to be “org.springframework.orm.hibernate3.SpringSessionContext”; because this is also the default, the explicit definition of the property can be removed.


Each DAO will be based on an parametrized, abstract DAO class class with support for the common generic operations:

public abstract class AbstractHibernateDAO< T extends Serializable >{
   private final Class< T > clazz;
   SessionFactory sessionFactory;
   public void setClazz( final Class< T > clazzToSet ){
      this.clazz = clazzToSet;
   public T getById( final Long id ){
      Preconditions.checkArgument( id != null );
      return (T) this.getCurrentSession().get( this.clazz, id );
   public List< T > getAll(){
      return this.getCurrentSession()
       .createQuery( "from " + this.clazz.getName() ).list();
   public void create( final T entity ){
      Preconditions.checkNotNull( entity );
      this.getCurrentSession().persist( entity );
   public void update( final T entity ){
      Preconditions.checkNotNull( entity );
      this.getCurrentSession().merge( entity );
   public void delete( final T entity ){
      Preconditions.checkNotNull( entity );
      this.getCurrentSession().delete( entity );
   public void deleteById( final Long entityId ){
      final T entity = this.getById( entityId );
      Preconditions.checkState( entity != null );
      this.delete( entity );
   protected final Session getCurrentSession(){
      return this.sessionFactory.getCurrentSession();

A few aspects are interesting here – as discussed, the abstract DAO does not extend any Spring template (such as HibernateTemplate). Instead, the Hibernate SessionFactory is injected directly in the DAO, and will have the role of the main Hibernate API, through the contextual Session it exposes:


Also, note that the entity Class is passed in the constructor to be used in the generic operations:

public class FooDAO extends AbstractHibernateDAO< Foo > implements IFooDAO{
   public FooDAO(){
      setClazz(Foo.class );

The Maven configuration

In addition to the Maven configuration defined in a previous article, the following dependencies are addeed: spring-orm (which also has spring-tx as its dependency) and hibernate-core:



Note that the MySQL dependency is included as a reference – a driver is needed to configure the datasource, but any Hibernate supported database will do.


This article covered the configuration and implementation of the persistence layer with Hibernate and Spring 3.1, using both XML and Java based configuration. The reasons to stop relying on templates for the DAO layer was discussed, as well as possible pitfalls of configuring Spring to manage transactions and the Hibernate Session. The final result is a lightweight, clean DAO implementation, with almost no compile-time reliance on Spring. You can check out the full implementation in the github project.

I don't want your learning about Spring Persistence to stop here.
>> Get my "Spring Persistence" eBook and subscribe to my Email List
Published at DZone with permission of Eugen Paraschiv, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


John David replied on Tue, 2011/12/20 - 10:43am

I had always faced issues with using hibernate. Few of these issues are:

1- How to support complex queries and joins with hibernate?

2- It has also some performance bottlenecks.

I just need your comments on using plain jdbc and optimized queries instead of using persistance with hibernate. Also Spring has now an old technology to work with. Flex with Java integration is a much better approach.


Willie Wheeler replied on Tue, 2011/12/20 - 6:40pm

Take a look at Spring Data JPA. It provides a ready-to-go DAO framework. The developer writes interfaces and Spring Data generates the implementation using dynamic proxies. It can even generate query methods based on method naming conventions (e.g. findByUsername() will find entities having a given username).

Eugen Paraschiv replied on Wed, 2011/12/21 - 6:26pm in response to: Willie Wheeler

My next article is going to be on Spring Data.

Eugen Paraschiv replied on Wed, 2011/12/21 - 6:30pm in response to: John David

Thanks for the feedback.

On usage of plain jdbc, if you are OK with paying for the complexity and verbosity associated with it, and actually have a need for the added performance (not a hunch or a premature optimization but an actual, measured need - emphasys on measured), then go for it. Also Spring JDBC adds some nice support over plain JDBC. 

Regarding Flex and Java -that's neither here nor there - meaning that it may be better or it may not be, but it's not the subject of this article. 

Thanks again, 


Lkjds Rwer Lkjw... replied on Mon, 2012/01/02 - 10:47pm in response to: Eugen Paraschiv

Nice article ! Looking forward to your next article about Spring data .


AFAIK , Spring data only provides a ready-to-go DAO framework for the JPA 's EntityManager use . However , I want to use Spring data in Hibenate Session API because I don't think my application will change the persistence implemenation in the future and  I am more faimilar with Hibernate and it is more feature rich. It would be nice if you can provide your own opionion in using   Spring data but in Hibenate Session API in your next articles.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.