http://forum.spring.io/forum/spring-projects/data/53831-hibernatetemplate-vs-hibernatedaosupport-vs-direct-hibernate-access
引用
It Depends...
Originally posted by sudheshnaiyer View Post
Also in our application, we need to support around 700 to 800 concurrent users. We were debating whether spring and hibernate are the right choices.
The short answer is, yes, Spring and Hibernate are a great pair to start with. But a nuanced answer might be more helpful.
Fundamentally, you're really asking a capacity question: does my application running on a given software stack scale feasibly?
Scalability of the software stack -- Spring+Hibernate have been designed to scale, absolutely. These days, for new applications, Spring is a slam-dunk. Hibernate is very performant, itself, but like anything that works with the database, it's how you use it that makes the difference. But, yeah, it scales.
Design of your app -- Ironically, this is the greatest source of performance (and thus capacity) problems. In general, application frameworks are developed with performance in mind. Doing things like querying the database repeatedly for the same data, or using lots of queries when one will do (so-called N+1 selects) or over synchronizing are the real source of performance problems. I would recommend spending less time debating about which framework to use and far more time digging in and learning how to use a given technology stack efficiently.
Usage patterns of your app -- your application's performance is really about how efficiently it responds to what your users do. Let's say there's a page that users are hitting A LOT in a typical session; tuning the design of that part of the app so that it's cheap and fast will decrease how much it "costs" to service a typical user and thereby increase your capacity. Again, it's not about the frameworks, it's about the quality of the application code.
Feasibility -- given all these factors, the final part is finding out how much hardware is required to handle the number of target concurrent users.
Let's say you have a simple set-up: a single application server doing both front-end and back-end processing. You develop performance tests that simulate (as best you can) typical user actions on your site (complete with "think time" -- users sitting there reading the screen). Then you run that test repeatedly, ramping-up the # of users (even better if you randomize the start time for each user). All the while, you measure the response time (i.e. how long it takes from request to completed web page). Decide what's an acceptable response time (e.g. shopping pages are 1-5 seconds; check-out is 30-60 seconds). Once you start to exceed your acceptable response times, you check the number of concurrent users. That's how many users are supported by one application server. Let's say it's 300. Then in your case, you'll need 3 application servers (assuming the DB can handle that full load).
There's lots of performance testing tools out there. I've had lots of success with Grinder: it's open-source, it gives you the tools you need to write meaningful tests and generate plenty of load, and it records the right metrics.
Bring the framework debate to a conclusion, fast; then spend the balance of your time getting smart about how to efficiently write your app.
Originally posted by sudheshnaiyer View Post
I have seen in lot of forums and still in confusion. We are starting a new project and need to
decide whether we need to decide which strategy to use:
Accessing Hibernate directly
Using HibernateTemplate
Using HibernateDAOSupport classes
Taking a step back, when discussing using Hibernate within a Spring app, there are three core questions:
Who will manage the lifecycle of the Hibernate Session?
Who will manage the Transaction?
How much of Spring's Hibernate-templating will you use in your DAOs?
Lifecycle of the Hibernate Session
To keep this simple, start with the goal of having a Hibernate Session open for the entire request. This is known as the "Open Session In View" which highlights the fact that the Hibernate Session remains open even in the view layer (e.g. inside your JSP that's rendering the response).
Hibernate's Session Management
Hibernate has a concept of "Contextual Sessions". Hibernate itself can store the current Session in one of two places for you: either on ThreadLocal or the JTA Session Context. Which place Hibernate uses is configurable (see section 2.5 in the Hibernate 3.3.1 Manual for instructions). This behavior is invoked when sessionFactory.getCurrentSession() is called. If a Hibernate Session doesn't already exist, one is created.
The key here, is that in order for this mechanism to kick in, the calling code (either application code or Spring) must call sessionFactory.getCurrentSession().
Spring's Hibernate Session Management
Spring also has a strategy of storing the current Hibernate Session on ThreadLocal. However, it is using its own storage, separate from where Hibernate would store the Session.
All of Spring's Hibernate supporting classes are aware of this storage:
OpenSessionInViewFilter and OpenSessionInViewInterceptor -- which start a new Hibernate Session at the start of an HTTP request and puts it in this ThreadLocal storage. (The ...Interceptor variety is used within Spring's Web MVC framework).
HibernateTransactionManager, HibernateTemplate, and HibernateDaoSupport -- all first check this ThreadLocal storage for a Hibernate Session; if none is found, creates a new one.
In fact, if you configure the Hibernate SessionFactory as a Spring Bean (using Spring's LocalSessionFactoryBean), that FactoryBean will automatically hook-up Hibernate to use Spring's Session Storage (just described), thereby merging the two and allowing the co-mingling of both raw Hibernate API and Spring's Hibernate Support classes, seamlessly. (nice!)
Therefore, the best approach to begin with is using the Spring-managed Hibernate Session approach. It is the responsibility/dominion of the application framework (here, Spring) to manage the lifecycle of such resources, anyway. If you DO choose to make use of Spring's support for Hibernate in your DAOs, the integration is seemless and easy. If you'd rather drop down and use the Hibernate API, directly, that's very easy to do too. So, you don't loose any flexiblity with this choice.
In most web apps, let Spring manage the Hibernate Session: configure either the OpenSessionInViewFilter in your web.xml or the OpenSessionInViewInterceptor in your Spring Application Context.
Transaction Management
Again, both frameworks provide transaction management integration facilities. Without going into much gory detail, if you're already using Spring, it's a slam-dunk to use Spring to configure the transaction management.
Use Spring's Transaction Management.
DAO Authoring Style
Given all this information to this point, hopefully it is clear that it merely becomes a question of style as to whether you use a HibernateTemplate, HibernateDaoSupport or straight Hibernate.
Hibernate API
The advantage of using the Hibernate API directly is that it will be familiar to those who already know Hibernate and you'll be able to use example snippets coded to this API.
The disadvantage of use the Hibernate API is that you don't get the benefits of Spring's DataAccessException translation. Which, depending on your shop, you might care about this.
Generally speaking, if you're committed to using Hibernate, this is not a bad choice.
HibernateTemplate
This is the first level of Spring's coding support for Hibernate. It eliminates the need for doing anything with the Hibernate Session, at all. It looks for a current Hibernate Session for you; if one exists, it executes the requested operation on that session. This is great for turning your simpler Hibernate code into one-liners.
Also, Hibernate Exceptions are automatically converted to Spring's DataAccessException hierarchy.
HibernateDaoSupport
This is the second level of boilerplate removal Spring addresses with respect to Hibernate. This is a base class from which your DAOs extend. HibernateDaoSupport wraps a HibernateTemplate and includes the corresponding getter/setter definitions you would normally have to duplicate across your DAOs.
Note that as of Java 1.5, with the inclusion of Generics, you can take this one step further and create a GenericDao.
How you code your DAOs is really a question of style, but Spring's supporting classes genuinely reduces boilerplate code and are recommended.
I hope this helps. Good luck!