The Open-Session-In-View pattern is a very popular strategy for managing open hibernate sessions for the duration of a request in a server side java web application (possibly for other technologies as well). Basically the pattern uses a servlet filter to open a session on each request as soon as its received and then on completion of processing closes the session. Some people love it, some hate it, and some just use it because they don’t know what else to do. As with anything I think that there are times to use it and times when its not appropriate. I want to provide some guidelines which I have found are helpful in understanding when it is appropriate.
I’ll assume you know the problem this pattern solves so we won’t talk about that (check out this link for discussion on that). But we’ll need to at least discuss the major implication of the open-session-in-view which is a database connection open for an entire request then cover the guidelines which fall out of that.
Database Connection Open for the Entire Request
Because the pattern is opening a hibernate session first thing on each request which implies that a database connection could be open for basically the entire request. For the purpose of this discussion we’ll assume that the open session ALWAYS correlates to an open database connection for the entire request. In the default case with many versions of hibernate, an open session doesn’t open a connection until it is needed but lets assume the worst case scenario. This will ensure that the pattern is match for you in all situations.
Problems with Open Sessions
If you have an open session over your entire request which is going to have an open database connection associated with it, the problem is that you will be tying up a database connection which is a limited resource in any setting for work which doesn’t necessarily involve the connection. Unless your in a high traffic application this generally won’t affect you but later I’ll show where it could even without large traffic volumes.
Why Most People Don’t Mind Open Sessions
Now most people probably don’t care about having an open session for the entire request or a database connection because in today’s relational database driven web world in a majority of cases 90+ percent of your overhead in a request time is database word anyways. So an extra 10% of time for a session or database connection is worth the cost to drive down complexity in your application.
Exceptions to the Trade Off
The exceptions to this trade off hopefully becomes pretty clear, when you have application logic which is going to consume most of the processing time of a request the trade off for driving down complexity loses to excessive session and connection time. In many cases your talking a minority of requests which fall into this trap so overall the trade off is still worth it you just need a couple workarounds. In a high request volume situation which limited resources for hibernate sessions/database connections your open-session-view could become a liability.
Guidelines for Open-Session-In-View Usage
- Use it when it only when it drives your code complexity down! This pattern isn’t for all applications. when you have complex database interaction either involving multiple databases or complex transaction strategies, it may not make sense. Or if you don’t have hibernate lazy loading issues happening its probably not useful either.
- Use when the session/database connection usage is a HIGH percentage of a request’s processing time already. When looking at each request which involves hibernate session/database access and check to see if thats the vast majority of processing time in the request. If this doesn’t apply then either think about another pattern or creating an exception case for those types of requests via filter or some other means.
- Use when the only threat to request time is database access itself. If there is potential for something to go wrong like a HTTP to get hung because not timeout is set then this about creating an exception for those types of requests or think about another pattern.
- Use when a HIGH percentage of ALL requests filtered require session/database connection access. If you have an application which a low percentage of requests which come into it need database interaction AND you cannot distinguish these requests via your filter or some other means, then don’t use this pattern.
- The pattern is preferably used on lower request volume applications. Just a preference in case you are trying to squeeze application resources.
Examples of Where to Avoid Usage
- File upload requests – most cases this isn’t an issue but the right combination of semi-large file and slow client network connection could tie up an open session/database connection for some time. Potentially timing out the database connection.
- Requests which trigger Service calls – specifically I’m thinking of web service calls where if the timeout on the socket then if the service becomes unresponsive then you’l potentially time up an open session/database connection. Again potentially timing out the database connection.