13

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.)

Marvo
  • 17,845
  • 8
  • 50
  • 74

2 Answers2

23

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.

gkamal
  • 20,777
  • 4
  • 60
  • 57
  • I have been going from here to there and then to there, skipping about the web on this topic for a week... and that's the first time I've read that Spring has an OpenSessionInView filter. Thank you. – Marvo May 19 '12 at 21:37
  • I always thought it would work as a transaction. But really the transaction is limited by spring's @Transactional. Thanks for the explanation. – digao_mb Aug 05 '14 at 17:10
0

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.

peterh
  • 11,875
  • 18
  • 85
  • 108
  • 1
    What we arrived at is to use the OpenSessionInView filter (see above) in combination with the Spring @Transactional annotation. So far, it works great. – Marvo Jan 17 '13 at 19:03
  • @Marvo I didn't have so good experience with that. You don't have control, what exactly happens and why. In my last project I had multiple database connections (some entities connecting the first, some to the second) with cross-directing spring layers, and some of the processes was from Quartz initiated, some from the web. The situation was complex and the main problem was that in an annotation- or/and AOP-based thing your have very-very control to check, what failed or where is the problem. It simply works or not, but you can't see in them. In a clear procedural environment it is trivial. – peterh Oct 24 '14 at 14:36