I am new to both Hibernate and Spring Framework. Could somebody tell me the benefits of using Spring Framework on the top of Hibernate? Since now we add another layer on top of Hibernate, would that affect performance?
Hibernate doesn't provide production-suitable connection pool (my understanding), does Spring provide production-ready pooling? What about the transaction?
Are you talking about using the Spring web framework along with a hibernate controlled DB connection? If so there should be no performance hit as they are layers with completely seperate functionality. If you are talking about Springs DB layer I don't think you would run both hibernate and that as they are different solutions to the same problem.
As far as hibernate being production ready, I haven't heard anything to say that it isn't, but I am by no means a hibernate expert.
Originally posted by Lilly WS: Hibernate doesn't provide production-suitable connection pool (my understanding), does Spring provide production-ready pooling?
Hibernate's built-in connection pooling implementation is not of production quality. However, Hibernate supports using a number of other connection pooling implementations that are production quality -- including C3P0, Apache DBCP and Proxool.
Here's a nice description of how to configure each of these.
Originally posted by Lilly WS: What about the transaction?
Hibernate has its own Transaction API that you can use. If you want to use the Transaction API, you have two alternative TransactionManagers/strategies to choose from: net.sf.hibernate.transaction.JDBCTransactionFactory which delegates transaction management to the JDBC driver (this is the default strategy) or net.sf.hibernate.transaction.JTATransactionFactory which delegates to the application server's JTA implementation.
Refer to the documentation for details on how to configure these.
Originally posted by Lilly WS: I am new to both Hibernate and Spring Framework. Could somebody tell me the benefits of using Spring Framework on the top of Hibernate? Since now we add another layer on top of Hibernate, would that affect performance?
While it does add another layer on top, it's a small layer that performs transaction processing (see below) and exception translation only. Compared to the database-intensive work that Hibernate does, this is trivial and you won't notice it.
Spring has given us a few benefits so far.
Easier configuration of Hibernate (not super exciting, but it's there). See below for our Hibernate configuration.
Nicer unchecked exceptions. I don't know where you stand on the checked/unchecked exception debate, but I'm squarely on the unchecked side, and Spring does the translation for you.
Thread-bound Sessions and Transactions
[list]Two forms of abstraction for making Hibernate calls: callbacks and templates. I went with the template approach. Here's the insert method from my framework DAO:getHibernateTemplate() returns a HibernateTemplate (implements Session interface) that wraps the real thread-bound Session, opening one if necessary). You never have to deal with Sessions again![list]Declarative transaction management a la EJB's CMT. This would be worth 10 times the price of admission if Spring cost anything. Here's how I declare the transaction states for the methods in my managers:It follows the same rules of CMT: if you throw an unchecked exception, it rolls back the transaction; otherwise it commits it when exiting the method -- all automatically.
Unrelated to Hibernate, Spring makes wiring up business objects a breeze. Instead of littering your code base with "getInstance()" methods that return singleton DAOs and other business objects, you declare them in an applicationContext.xml file and wire them together there. The BOs are standard JavaBeans that use getter/setter methods to wire and access related beans. And Spring provides a mechanism to turn them into non-singleton prototypes, so each time a bean asks for another bean, you can set it up so that the new bean is always a new instance. You only need to do this if your beans keep state, which I think is unnecessary in general, especially so with thread-bound transaction managers and sessions.
I hope this helps answer your question. I may sound like the poster child for Spring, but it has boosted my productivity a lot, taking care of details that are simply no fun. I wholeheartedly recommend it, and it compliments Hibernate nicely.
Oops, forgot to add my configuration. Here it is: [ February 03, 2005: Message edited by: David Harkness ]
Joined: Aug 07, 2003
Oh, and you might be wondering what "org.springframework.jdbc.support.lob.OracleLobHandler" is. This handles BLOBs and CLOBs in Hibernate for you. I just map Strings and bytes in my domain objects and specify "org.springframework.orm.hibernate.support.BlobByteArrayType" as the type in the mapping file and that's it. I honestly can't say what you need to do with Hibernate alone, but when I looked it up a while ago it looked more complicated than that.
Joined: Jan 20, 2005
By the way, Lilly, would you mind editing your display name to include a full last name -- it's required by our naming policy.
How do you know 'WS' is not my last name?
Anyway, I have changed - hope Lasse feels a little happier My apology.
Joined: Jan 20, 2005
You definitely get me convinced. I am in - to incorporate Spring to Hibernate.
Thanks for the input. That helps a lot.
Lasse and Steven,
Thanks for your help as well. Very good information.
Joined: Aug 07, 2003
Glad to help, Lilly. There will be a learning curve with Spring, just like Hibernate, but I found it to be much easier to grasp than Hibernate. And the Spring documentation is very clear.
I recommend picking up Expert One-on-One J2EE Development without EJB by Rod Johnson. While not specificlly about Spring, he's the principle architect of it and touches on a lot of concepts. Unfortunately, Professional Java Development with the Spring Framework isn't scheduled for release until mid-May.
There's also Spring Live, but I haven't looked at it. Honestly, it just wasn't that hard to set up. There a couple of tricks that I found in the docs, so if you have questions fire away.
Wow, now I see two other new Spring books: Spring in Action (usually a good series -- I might have to pick this up) and Pro Spring. No reviews for either of those books on Amazon, though. [ February 03, 2005: Message edited by: David Harkness ]
Joined: Jan 20, 2005
Thanks for the reference. As a matter of fact, I was reading Expert one on one J2EE without EJB. It's a pretty good book, with a little a little bit reduntcy.
I'll play around so I can get a feel. It seems a little easier than Hibernate. Hope it's not too hard to learn.
We've had great results with the Spring Framework also using in our case JDO for database access.
For Web applications, wiring-up of business services and controller objects, and portable configuration, Spring is the greatest thing since sliced bread. :-)
Spring also offers a couple of approaches to wrap data-access code, as David mentions. Our decision was to retain a vanilla approach and request a session, only when we needed a session. Spring greatly simplified the wiring of the application and almost halved our time-to-release.
Actually, didn't Spring invent modern sliced bread?
Seriously, I cannot agree more. I recently needed to add a utility class to acquire an Oracle sequence value directly (not as a surrogate key via Hibernate). Using JdbcTemplate.queryForInt(), the non-constructor/accessor method was one line.
Spring definitely delivers insane productivity improvements.
Believe it or not it gets even easier if you use one of Spring's convenient DaoSupport classes, for instance HibernateDaoSupport. Most of your Hibernate data access becomes simple one-liners. Check this out from one of my apps:
Besides having a common set of DataAccessExceptions for all its data access strategies, it also has these convenient DaoSupport classes for each of the strategies.
The following is a snippet from the configuration file:
Now on top of all that easy data access, you get easy declarative transaction management for the business objects that use your dao's thanks to the TransactionProxyfactoryBean, and without the pain of using EJB !!!
Sweet [ February 08, 2005: Message edited by: Ken Krebs ]
kktec<br />SCJP, SCWCD, SCJD<br />"What we observe is not nature itself, but nature exposed to our method of questioning." - Werner Heisenberg
Originally posted by David Harkness: Oh, and you might be wondering what "org.springframework.jdbc.support.lob.OracleLobHandler" is. This handles BLOBs and CLOBs in Hibernate for you. I just map Strings and bytes in my domain objects and specify "org.springframework.orm.hibernate.support.BlobByteArrayType" as the type in the mapping file and that's it. I honestly can't say what you need to do with Hibernate alone, but when I looked it up a while ago it looked more complicated than that.
David, can you elaborate on this? I'm trying to use Hibernate3, Spring12 and Oracle8i with CLOBs. No matter what I use I generally get 2 conditions - if I set lazy="false" in my mapping file then I get null when using find or get, and "No row with the given identifier exists" using load method of HibernateTemplate. If I set lazy to true then I get error that my session is no longer valid.
I set CLOB mapping to org.springframework.orm.hibernate3.support.BlobByteArrayType in my NMB file and map CLOB fields to Strings in POJO