Question

I have just started using Hibernate with HSQLDB. In the tutorial they tell me not to use the anti-pattern “session-per-operation”. However, each time I commit a transaction the session is closed as well. How am I supposed to avoid using getCurrentSession() if commit() closes the session?

I’m a bit curious on how people usually hande the scope of the session. I have seen several samples on building web applicatons where you have one session per request. In my case I’m building a service, and cannot apply the same idea. The service is running 24/7, and sporadically it does some database operations. Should I keep the database session alive all the time, and just use transactions as boundaries between operations (considering a case where my transaction commits do not close the session) or should I just create a new one for each operation (which is the anti-pattern, but how else?).

Thanks in advance!

Answer 1

That behaviour is determined by the implementation of CurrentSessionContext in use. The default happens to be ThreadLocalSessionContext which does close-on-commit, but you’re by no means constrained to that.

You can configure/build any type of session scope you like by using ManagedSessionContext and binding/unbinding sessions at the appropriate beginning and end of life cycle. It seems to make sense for you that you would bind a Session at the entry to your service’s unit of work and unbind it at the exit. (It is of course no trivial task to build robust code for doing this. Particularly remember that you’re expected to make a new Session if an exception comes out of one of its methods.)

---

Responding to comment was getting too large for a comment.

That is the default behaviour because it’s the only thing that’s “safe” without additional work or configuration provided by the user. The “commit” is the only lifecycle point that Hibernate is able to “see” if you don’t help it out, so it has to close there or risk the session being left dangling forever.

Determining potential session life cycle boundaries requires a fair bit of knowledge about what you’re actually doing. “It’s a background service” isn’t much to go on. Assuming it does something like sit idling and wake up every X minutes, do some work, then go back to sleep for another X minutes, then that would be a good boundary to open then close a session.

You may be using an over-broad definition of ‘operation’ when talking about ‘session per operation’ being an anti-pattern.

They mean don’t do something like (fictitious requirements for your service):

1. Wake Up Service
2. Open Session
3. Read File location from database
4. Close Session
5. Open file
6. Open Session
7. Update Database tables from current file state
8. Close Session
9. Open Session
10. Write Activity Log to Database
11. Close Session
12. Sleep Service

It would be perfectly reasonable to do that in one session then close it at the end. In a single threaded environment where you’re managing everything yourself within known boundaries, you can really just open and close the session yourself without using currentSession if you want. You just need to make sure it gets closed in the event of an exception. If you’re listening for an operating system event, the event handling would be a perfectly fine scope for the session.