Technically, Spring's Open Session in View support does not use a resource transaction but rather only uses auto-commit mode for any data access during view rendering (i.e. equivalent to short read-committed transactions for each such lazy loading statement).

So Adrian's point applies: Resource transactions should only be used for the controller part of the request lifecycle, not during view rendering. Of course, your point applies as well: Open Session in View style lazy loading is still fine during such view rendering!

However, if the controller part of the request lifecycle throws a HibernateOptimisticLockingException, then lazy loading fails during the view rendering (LazyInitializationException). Surely it is better to start a read-only transaction around the view rendering, hence avoiding this problem?

[However, I have not yet found a simple way of doing that - my current approach involves implementing a custom ViewResolver which returns proxy Views which take care of the read-only transactions….. any neater ideas would be appreciated!]

So Adrian's point applies: Resource transactions should only be used for the controller part of the request lifecycle, not during view rendering. Of course, your point applies as well: Open Session in View style lazy loading is still fine during such view rendering!

—-
· Don't underestimate the cost of web content rendering. You definitely want to do this outside of a transaction.
—-

Sorry for the mess,
Daniel.

But here comes that 2% I don't agree with (until you convince me ):

>

Isn't this like stating that "Open Session in View" is some kind of anti-pattern? Or with that word "transaction" you mean "business logic read/write transaction"?

I mean: in my opinion, if we assume that painting some tags in a JSP is a very light operation and that we are not exporting some kind of one-thousand-lines unbuffered listing (which is the true scenario 90% of times), the *real* cost of web rendering will only come from SELECT queries on the database triggered from, for example, navigating some lazy associations in the view layer.

But we navigate these data because we need it to be shown, and are going to query for it anyways, be it while painting the view or before, at the controller or even business logic. So we won't really save in query time if we do queries before painting the view (okay, we can have wrongly configured lazy fetching settings). Even more, the business logic will certainly *not* be the place to do those view-helping queries as they are exclusively read-only and thus will perform better in a read-only transaction…

So, could you explain a little further on this topic? Are you really dismissing Open Session In View? If so… why?

Thanks for your work, and for sharing it.

Regards,
Daniel.