Where to open sessions in a Spring/Hibernate stack?

Question

I'm trying to figure out a good design for a Spring/Hibernate app. When creating such an app, it appears like there are a handful of major decisions.

The first major decision seems to be where to put the session/transaction boundary. It seems like I have 3 major choices: as a filter before controllers are even invoked, immediately below the controllers at the service call level, and stuffed way below the business level in repository calls.

It seems to me like the right call is the middle path, but I'm not sure. I don't want my transactions open too long, but at the same time, I don't want to constantly worry about detached objects and lazy loading in the business logic. Still, there are some downsides. For instance, it makes it hard for the business logic to make a remote call without holding up a transaction for a few seconds. I wonder if there's a better way?

Answer 1

It depends on how you have modularized the code. I'm assuming you have not written all your DB transaction related code in your controllers. In case you have separated your code to DAO or Service layer which takes care of the transactions it makes sense to have the granularity only as much as it is required.

It isn't a good design to keep the transaction hogging for a long time, so having the filter open the session is probably a bad idea. Unless, you have some lazy loaded objects for which you wish to open the session.

If the above is not applicable, then you can have the transaction/session boundary around your data access layer only.

Answer 2

Solution 1 : open session in view filter

• Advantages :
  • you won't encounter lazy initialization exceptions, so you can use your model objects in your view without thinking twice
  • you won't have to worry about your controller doing its work in different transactions if you make several service call (if an error occur during the second service call, your first call won't be rollbacked).
• Drawbacks :
  • longer transactions
  • if an error occurs at commit (a data constraint violation for example) you will have already written on the response output stream most of your view, so you won't be able to show error page (unless you use another filter above the 'open session in view' one that will store the outstream until the commit is done, and only then send the generated page to the client or redirect to an error page)

Solution 2 : transaction boundaries at business layer

• Advantages :
  • More flexibility at controller level (but that can be a curse if you have members of your team that don't really understand transactions, and place too much logic at controller level, using several tx where there should have been only one)
  • less resource use (as you give back db connections to the pool faster)
• Drawbacks :
  • You will need to use object of your model carefully when outside of your transaction layer. The simplest way of avoiding lazyInitialization exception is perhaps to use DTOs, and have each service implementing two interfaces (one extending the other) : one that only contains method returning DTOs, and the other only methods returning objects of your model. You will use the first interface in declarations in the controller, and use the second one only in the business layer, where a transaction is still open, so returning a model object can't lead to a lazy init exception.

Solution 3 : transaction boundaries at dao layer

Unless your dao methods contains business logic, there is no point in having transaction limited to a dao call. That's way to close to 'autocommit' mode to be useful i think.

---

In any case, if you wish to keep your transaction short, i advise you to watch closely the 'sql footprint' of every business use case (by setting the org.hibernate.SQL log category to DEBUG) and compare the produced sql with what you would have written yourself.

Most of the time i've seen slow use case, it was because hibernate lazy loading feature was not configured correctly (it was either too eager, adding twelve levels of join in each query, or too lazy, issuing a query by element of collections)