Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>That behaviour is determined by the implementation of <a href="http://docs.jboss.org/hibernate/core/3.5/javadoc/org/hibernate/context/CurrentSessionContext.html" rel="nofollow">CurrentSessionContext</a> in use. The default happens to be <a href="http://docs.jboss.org/hibernate/core/3.5/javadoc/org/hibernate/context/ThreadLocalSessionContext.html" rel="nofollow">ThreadLocalSessionContext</a> which does close-on-commit, but you're by no means constrained to that.</p> <p>You can configure/build any type of session scope you like by using <a href="http://docs.jboss.org/hibernate/core/3.5/javadoc/org/hibernate/context/ManagedSessionContext.html" rel="nofollow">ManagedSessionContext</a> 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 <code>Session</code> if an exception comes out of one of its methods.)</p> <hr> <p>Responding to comment was getting too large for a comment.</p> <p>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.</p> <p>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.</p> <p>You may be using an over-broad definition of 'operation' when talking about 'session per operation' being an anti-pattern. </p> <p>They mean don't do something like (fictitious requirements for your service):</p> <ol> <li>Wake Up Service </li> <li>Open Session </li> <li>Read File location from database </li> <li>Close Session </li> <li>Open file </li> <li>Open Session </li> <li>Update Database tables from current file state </li> <li>Close Session </li> <li>Open Session </li> <li>Write Activity Log to Database</li> <li>Close Session </li> <li>Sleep Service</li> </ol> <p>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 <code>currentSession</code> 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.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload