Is there an advantage to using Spring to manage the session factory and transactions?

Have a look at the article at http://www.hibernate.org/110.html. It gives an overview of what values Spring can add to Hibernate. Two important values in the middle tier area are:

Configuration management

Spring can wire your entire middle tier in a loosely coupled fashion (yep, those IoC and AOP buzzwords ;-):

- resources like JDBC data sources and Hibernate session factories
- data access objects that access those resources
- business objects that delegate to your DAOs for persistence

This completely avoids the need for custom singletons or the like that hold configuration information, SessionFactory references, etc. You have one homogeneous style of configuration throughout your middle tier then. Spring cares for the entire lifecycle of your middle tier objects.

Spring provides means to link in JNDI resources into such definitions, wiring them with your application objects, without the latter being aware of JNDI. Alternatively, you can easily use local resource definitions, like a local Commons DBCP BasicDataSource.

Spring's LocalSessionFactoryBean is a convenient way of setting up a Hibernate SessionFactory in a Spring context, as an alternative to fetching the SessionFactory from JNDI. It provides all of Hibernate's configuration power, avoiding the need for a separate hibernate.cfg.xml file.

Transaction management

Transaction management is one of the most important Spring features. You have the choice between programmatic and declarative transaction demarcation, with pluggable transaction strategies: JTA, JDBC, Hibernate, JDO. (You just need JTA for actually distributed transactions.)

A popular usage is to proxy your business objects with Spring's AOP TransactionProxyFactoryBean, with HibernateTransactionManager as strategy. Each business service invocation will then automatically execute within a proper Hibernate transaction; DAOs will simply participate.

So Spring helps to separate transaction and data access concerns, avoiding the need for passing around Hibernate Sessions or using custom ThreadLocals. Multiple DAO invocations within a single transaction are seamless to achieve, reusing the same Hibernate Session.

Essentially, Spring's middle tier support offers similar services like local Session Beans but for POJOs - just like Hibernate offers persistence for POJOs as alternative to the Entity Beans component model. Spring and Hibernate are absolutely complementary here.

Juergen

Hi, I have a question about this statement:

Multiple DAO invocations within a single transaction are seamless to achieve, reusing the same Hibernate Session.


I'm would like the same Hibernate Session (and Transaction) to be used accross multiple DAO's but Spring seems to be getting a new Session each time SessionFactoryUtils.getSession(...) is called. Here's the simplest example I can give:



which gives this output:



Am I correct that this is creating 2 Sessions?

Is this the expected behavior or am I doing something wrong? Do I need to use OpenSessionInViewInterceptor or OpenSessionInViewFilter to do what I want?

Here is part of my applicationContext.xml




I am running Spring rc2, Hibernate 2.1 with Tomcat and MySQL

Thanks for any help!

- Ryan

Ryan,

You don't seem to demarcate a transaction anywhere: In this case, each of your data access invocations will execute non-transactionally, i.e. within its own Hibernate Session.

As a side note, you need to close the Sessions you open with SessionFactoryUtils.getSession, via SessionFactoryUtils.closeSessionIfNecessary. Consider HibernateTemplate for a convenient one-line approach, handling Sessions under the hood.

You can demarcate transactions programmatically or declaratively: In the latter case, a simple way is to proxy your DAO (or a higher-level business object that delegates to your DAOs) with a TransactionProxyFactoryBean. Your data access logic will seamlessly participate in any such transaction, allowing for flexible reuse behind a variety of business facades, with a variety of transaction strategies.

Have a look at sections 5 to 7 of the article at http://www.hibernate.org/110.html for a discussion, and at the Petclinic sample app that comes with the Spring distribution for a working example of transactions with a Hibernate DAO.

Juergen

Ok, I guess somehow I missed that setting up transactions is required. I think I assumed Spring would use the session-per-request pattern rather than session-per-operation by default (http://hibernate.bluemars.net/168.html)

It works great now, thanks.

- Ryan