Hibernate Open Session in View: Transaction per Request?

Question

I'm using Hibernate with Spring on Tomcat. I've been reading and re-reading the oft pointed to JBoss wiki page on the topic, and that has been helpful. But it leaves me with some questions.

1. The idea of starting a transaction for every request troubles me. I guess I could limit the filter to certain controllers -- maybe put all my controllers that need a transaction under a pseudo "tx" path or something. But isn't it a bad idea to use transactions if you don't know if you're going to need one? And if I'm just doing reads in some request -- reads that very likely may come from a cache -- aren't I better off without a transaction?

2. I've read posts mentioning how they handled the transactions at the service layer, and I'd like to do this with Spring. But then what does the filter code look like? I still want the session available in my view for some lazy loading.

3. If all I have to do is call sessionFactory.getCurrentSession() in my filter, how does it get "freed" back to the session factory for re-use? (I expected to see a session.close() or something, even when using transactions.) Who is telling the session factory that that session can be reused?

4. Perhaps it's the beginTransaction() call that binds a given database connection to a given session for the duration of a request? Otherwise, a session pulls db connections from the pool as needed, right?

Thanks for your patience with all my questions.

(And if your answer is going to be a link to the Spring documentation, you'll just make me cry. You don't want that, do you? I'll pay real money if people would stop answering Spring-related questions that way.)

Answer 1

Your concerns are valid, the solution provided on the wiki page is too simplistic. The transaction should not be managed at the web layer - it should be handled at the service layer.

The correct implementation would open a session and bind it to a thread in the filter. No transaction is started. The session is put in flush mode never - read only mode. A service call would set the session to flush mode auto & start / commit the transaction. Once the service method finishes the session flush mode is reverted back to never.

There is also an option to not open the session in the filter. Each service layer call would open a separate session & transaction - after the service call is done the session is not closed, but registered for deferred close. The session will be closed after the web request processing is complete.

Spring provides OpensessionInViewFilter which works as described above. So ignore the jboss wiki article and just configure the OpensessionInViewFilter - everything will be fine.

SessionFactory.getCurrentSession() - internally creates and assigns the session to a thread local. Each request / thread will have its own session. Once the web request processing is complete the session will be closed. From within your code you just need to use SessionFactory.getCurrentSession() and don't have to close it. The code sample on the jboss wiki page is wrong - it should have a SessionFactory.getCurrentSession().close() in the finally block. Or they might be using JTA transaction and configured hibernate to open/close session in conjunction with the JTA transaction.

Answer 2

It is not a problem if the filter creates a session for every request, because the sessions are coming from a session pool, and they will be reused. From the view of the OS, nothing happens.

A hibernate session is, by the fact, a tcp (or socket/pipe) connection to the database server. The cost of the db conn creation is very dependent from the sql type (postgresql is notably bad in this, altough it is very good in every anything). But it doesn't means really anything, because hibernate reuses the database connections.

The simple hibernate filter solution starts a new transaction on the session for every requests, too. It is transaction from the view of the SQL: it is a "BEGIN" and "COMMIT" query. It is always costly, and this should be reduced.

IMHO a possible solution were, if the transactions were started only at the first query of the current request. Maybe spring has something usable for this.