Best way to handle Hibernate Sessions in a layered Spring MVC Web application

Question

If we have a web application which has

• heavy UI (Spring MVC + JQuery with JSON)
• Hibernate with JPA annotations being the domain model
• ext

Answer 1

• Use JPA EntityManager directly in your DAOs. Be sure not to mark it as Extended
• Prefer <tx:annotation-driven /> and @Transactional - only on the service layer
• The transaction manager also opens and closes sessions (if one doesn't exist already in the thread). Here it is good to know that sessions are session-per-request. Each request(=thread) has a separate session instance. But a database connection is created only if one is needed, so even if there is a transaction manager around all methods, needless connections won't be opened.
• read-only transactions - use @Transactional(readOnly=true) in cases when there is only data retrieval
• caching - utilize hibernate 2nd level cache to put entities in memory (instead of fetching them from the database each time)
• avoid OpenSessionInView and lazy collections. This is subjective, but in my opinion all objects that leave the service layer must be initialized. For small collections (for ex. list of roles) you can have eager collections. For bigger collections use HQL queries.

Answer 2

This sounds like a pretty typical Spring/Hibernate application, so I would recommend following current best practices, which I recently outlined in another answer. Specifically:

1. Do not extend Spring DAO support classes or use HibernateTemplate. Use the @Repository annotation combined with component scanning, and directly inject the SessionFactory into your DAO.
2. Use Spring's HibernateTransactionManager, and definitely use declarative transaction management via @Transactional as your default approach.
3. Let Spring manage that. It will open sessions just in time for transactions by default, but prefer the open session in view pattern enabled by Spring's OpenSessionInViewFilter.
4. See #3.
5. Always handle exceptions where they should be handled--in other words, this is a design decision. Note, however, that the Spring transaction framework by default rolls back on unchecked exceptions, but not checked, to match the behavior of the EJB spec. Make sure to set the proper rollback rules (see previous link) anywhere you use checked exceptions.

Additionally, use a connection pool, obviously. Apache Commons DBCP is a great choice. "Not much leakage in connection usage" isn't enough. You have to have zero connection leakage. Depending on Spring to manage your resources will help ensure this. As for any other performance issues, don't try to optimize prematurely. Wait until you see where your problem areas are, and then figure out the best way to solve each one individually. Since your bottlenecks will most likely be database-related, check out the performance chapter of the Hibernate reference to get an idea what you're up against. It covers the important concepts of caching and fetching strategies.