Re-consider including HibernateTemplate and related classes for Hibernate 4 [SPR-11291]

[spring-projects-issues]

Manuel Dominguez Sarmiento opened SPR-11291 and commented

We are well aware that the recommended approach nowadays is NOT using HibernateTemplate. However, projects exist that need to be upgraded to newer library versions, and the change needs to be as smooth as possible.

Recently, we needed to upgrade a very large project (about 100 DAOs) to Hibernate 4, for several reasons (mainly fixes that were not available in the 3.6.x branch). The project used HibernateTemplate for all DAO access (which was the recommended approach back when the project was started in 2005/2006). We found out the hard way that Spring did not provide a HibernateTemplate in the hibernate4 subpackage.

Before anyone cries out "refactor your code to use sessionFactory.getCurrentSession()" let me remind you that HibernateTemplate offers several extra features:

• Automatical exception translation to the Spring hierarchy
• Obtaining a new session automatically when a transaction is not active
• Filter configuration
• Query cache region configuration
• fetch size tuning
• max. results
• HibernateOperations API (which IMO is cleaner than direct Hibernate Session usage, and uses generics whenever possible while Hibernate Session does not)
• etc.

All of this can be refactored to use Hibernate directly. However, such refactoring is a big risk for a large project, and a huge opportunity to introduce regression bugs all over the place in the data access layer.

I'm sure that I'm not alone in the sentiment that Spring should provide a smooth migration path from Hibernate 3 to Hibernate 4. Currently it does not. If HibernateTemplate were an obscure, seldom used class, I would not have a problem. But HibernateTemplate use is widespread, given that it was the recommended approach for such a long time (even if a long time has passed since then)

---

Affects: 3.2 GA, 4.0 GA

Attachments:

• HibernateAccessor.java (13.64 kB)
• HibernateCallback.java (2.58 kB)
• HibernateDaoSupport.java (5.90 kB)
• HibernateOperations.java (46.88 kB)
• HibernateTemplate.java (43.79 kB)

Issue Links:

• Doc: Spring 3.x and Hibernate 4 are not compatible. Unable to use HibernateTemplate. [SPR-9365] #14002 Doc: Spring 3.x and Hibernate 4 are not compatible. Unable to use HibernateTemplate.
• HibernateInterceptor variant for Hibernate 4 [SPR-9028] #13667 HibernateInterceptor variant for Hibernate 4

1 votes, 4 watchers

[spring-projects-issues]

Manuel Dominguez Sarmiento commented

We have refactored the relevant classes from the hibernate3 subpackage to be usable for Hibernate 4 (see attachments)

The refactoring is not 1-to-1, but is pretty close to the originals. We've removed some features we do not use in order to simplify some of the code:

• Filters
• allowCreate flag
• alwaysUseNewSession flag
• HibernateInterceptor
• etc.

[spring-projects-issues]

Manuel Dominguez Sarmiento commented

The ideal migration path should be a simple search and replace:

Replace everywhere:
org.springframework.orm.hibernate3
with
org.springframework.orm.hibernate4

[spring-projects-issues]

Manuel Dominguez Sarmiento commented

This URL provides some background:
http://stackoverflow.com/questions/12158294/upgrading-to-hibernate-4-1-and-the-infamous-hibernatetemplate

[spring-projects-issues]

Manuel Dominguez Sarmiento commented

Related issues (I cannot seem to be able to link directly in JIRA):
https://jira.springsource.org/browse/SPR-9365
https://jira.springsource.org/browse/SPR-8096

[spring-projects-issues]

Karsten Klein commented

I completely support Manuels request. We are currently migrating a quite large code base that was using Hibernate 3.5.6 to latest Spring/latest Hibernate and simply can't live without a HibernateTemplate (going without would mean rewriting a frightening amount of DAOs and digesting a multitude of JUnit tests from different coding ages).

We basically did the same as described in this issue so far. We ported the required classes from the hibernate3 package to the hibernate4 package and threw away things we do not require in our case. I'm afraid, our decisions regarding all the transaction internals and resource management may not be the best and would rather like to see the "Spring Guys" providing this infrastructure as best fit with all the rest.

To be honest I currently cannot see that the "native hibernate DAO" approach works for us. I admit, that I may not have yet (if ever) grasped all aspects of hibernate transaction management, session factories and session, but for ages we have been happy that Spring ORM took that responsibility.

[spring-projects-issues]

Juergen Hoeller commented

Karsten, is your primary motivation for the upgrade to Hibernate 4.x a specific new feature there or rather the lack of bug fixes in the Hibernate 3.6.x line? We expected HibernateTemplate users to simply stay on the Hibernate 3.6 line...

The main reason for not providing a HibernateTemplate for Hibernate 4 was the strong opinions that the Hibernate team had about it. Back with our Hibernate 3 support, we had to argue about a HibernateTemplate port from our Hibernate 2.x package, and could only 'justify' it towards the Hibernate team with an argument about migration from Spring's Hibernate 2.x support.

So down that line of argument, providing a HibernateTemplate for Hibernate 4 would be a temporary migration help only. We could introduce it in deprecated form... but I suppose that's not what you're asking for? Fundamentally, you are interested in permanent usage of HibernateTemplate, aren't you? Did your custom HibernateTemplate port work so far for your purposes?

FWIW, using Hibernate 4 as a JPA provider is closer to Spring's HibernateTemplate style than Hibernate's own SessionFactory.getCurrentSession(): A JPA EntityManager uses short-lived sessions when called outside of a transaction but still participates in ongoing transactions, much like HibernateTemplate. I'm not suggesting a migration of all your data access code to JPA; I'm just trying to find out whether JPA would fit your expected programming style for a new project?

Juergen

[spring-projects-issues]

Manuel Dominguez Sarmiento commented

In our case I would be fine if it were introduced in "deprecated" form. The issue here is not with new projects, but with existing projects that need to move forward to Hibernate 4.x - in those cases re-factoring the whole DAO layer is most of the time either unfeasible or too dangerous.

[spring-projects-issues]

Juergen Hoeller commented

Locally experimenting with it, HibernateOperations is still quite applicable to Hibernate 4, except for HibernateCallback not needing to declare a SQLException anymore (since JDBC Connection access isn't available there anymore), and for 'executeFind(HibernateCallback)' to be superseded by the generically declared 'execute' method and therefore to be dropped completely. All the direct data access operations seem to be implementable against Hibernate 4 without any compromises to make.

Functionally, the biggest concern is the fallback behavior of creating a new Session for just a single operation. Since Hibernate strongly discourages that kind of model, I'm not a great fan of supporting it in any new HibernateTemplate variant that we may be introducing here. Since it's impossible to deprecate such a runtime mode, we'd rather have to not support it entirely. This is also a significant step to take towards easier migration to the Hibernate getCurrentSession() variant.

Therefore, a question to you guys: Could you live with a Hibernate 4 HibernateTemplate only working within transactions and other kinds of longer-lived Sessions (e.g. OpenSessionInViewFilter)? Related to that, could you live with no local flush mode options on HibernateTemplate itself, relying on proper flush mode setup of the underlying Session? (Note that there's still a "flush()" method on HibernateOperations, in case you really needed to trigger a flush before or after a specific operation.)

Juergen

[spring-projects-issues]

Manuel Dominguez Sarmiento commented

About 99% of our DAO code works within transactions. However, some of the DAO code does not, and it would be cumbersome to correct (mainly because of missing test coverage that would 100% tell us where transactional demarcation is missing for some edge cases). Therefore automatic transaction creation would still be useful. The classes I've attached are being used in production and do pretty much the same as Hibernate3's HibernateTemplate, save for the exceptions I've outlined above.

Regarding local flush modes, it is not something we use. So yes, at least in our case, I guess we could live without that.

[spring-projects-issues]

Juergen Hoeller commented

The problem with non-transactional execution is related to the flush mode issue: In a proper form, this will only work with flush mode 'manual' and read operations. Performing any kind of write operation requires a manual flush call and is essentially outside of Hibernate 4's intended usage patterns.

In JPA, they addressed this through explicitly only allowing read operations in non-transactional mode, and not performing any kind of dirty checking or flushing then. This is significantly cleaner than running plain Hibernate in non-transactional mode. My suggestion above basically makes HibernateTemplate behave exactly the same way as JPA there.

If you happen to violate this rule anywhere in your code, performing write operations outside of a transaction, I'd say you want to know about it. With the implementation as suggested, you'd get a descriptive InvalidDataAccessApiUsageException telling you at runtime. However, in practice, I've only seen people doing read operations that way anyway.

Juergen

[spring-projects-issues]

Manuel Dominguez Sarmiento commented

In our case, the few operations that use DAOs outside of transactions are effectively read-only. So I agree with your focus.

[spring-projects-issues]

Juergen Hoeller commented

Good news: We've decided to move forward with this for Spring 4.0.1 already, as a pragmatic aid in migration towards Hibernate 4.x, and also in preparation for official deprecation of our orm.hibernate3 package in Spring Framework 4.1.

Hibernate 3.6.10 as the last 3.6 maintenance release happened almost two years ago, so staying on the Hibernate 3.6 line is indeed not a long-term strategy anymore. As of this point, we officially recommend a migration to Hibernate 4.

Note that the orm.hibernate4 variant of HibernateTemplate is stripped down in terms of Session management options and just provides a current-session style with a fallback to a temporary session-per-operation. Furthermore, in the latter fallback mode, only read operations are supported, just like with a JPA EntityManager. The HibernateTemplate API for Hibernate 4 itself is not deprecated and intended to be supported for the entire Spring 4.x line.

Juergen

[spring-projects-issues]

Manuel Dominguez Sarmiento commented

This is great news! Glad this decision was made.

[spring-projects-issues]

Juergen Hoeller commented

FYI, I've updated the Hibernate section of our migration document on GitHub accordingly:

https://github.com/spring-projects/spring-framework/wiki/Migrating-from-earlier-versions-of-the-Spring-Framework

[spring-projects-issues]

Karsten Klein commented

I think the result pretty much satisfies our needs as well. In our case we try to reach 100% of all DAO access to happen within a transaction for production code. However, some unit tests do not behave well in that respect. But we are too cautious to throw them away and too conservative with our time-investment to redo them.

Stripping out the "fallback methods" of the template is a good idea. The fewer things that can be used incorrectly the better. Probably we on our side need to manage a painless migration path.

To answer some of the earlier questions:

• Hibernate 3.6 was never an option for us. The effort to migrate from 3.5 to 3.6 was regarded to be almost on the same scale as to go for Hibernate 4.3. The idea of working with a current code line, with active bug fixes is also too attractive in contrast to the short-term 3.6 strategy.
• we have a modular approach to develop our applications. This means that each and every module can consider different approaches with regards to implementing the internals (i.e. DAOs). The new DAO styles (native hibernate as well as the entity manager approach) is quite interesting to us. We will try to use it for new modules. However existing modules will stay as they are as long as we can maintain them.
• our current port of the classes from hibernate3 to hibernate4 works for us (so far) and we are looking forward to Spring 4.0.1 to remove bits and pieces again ;)