Hibernate version: 3.1.2

Java Version: 1.5.0_06

I'm taking a look at the Open Session In View code on the Wiki and in the Caveat Emptor application. I noticed that the Servlet Filter never calls session.close() in the Thread Local version. Is there a reason for this?

The Session javadoc for close() states " It is not strictly necessary to close() the Session but you must at least disconnect() it.".

The Filter Code I'm using is below. It's basically a copy of the code on the Wiki. I'm also using the Generic DAO pattern described on the wiki. That pattern says that no session management is needed in the DAOs.



My web.xml defines the filter as follows. I'm using dispatcher REQUEST to prevent include:jsp tags from invoking the filter again.



Thanks!
Don

The reason to not close a session, is to ensure the objects that are retrieved from the session are not detached.

Plus if we do not want to use "Open session pattern", we have to deal with reataching a detached object:
- Which object need to be attached if it has parent-child relationship?

We need to ensure cascade property is set up correctly and care must be taken when dealing with unidirectional object. I.e. A has getB() but B does not have getA(). This mean re-attach B does not make A to be persistent.

- How to reattach a detached object without causing any modified fields to be persisted upon transaction commit?

1. session.refresh() refresh the detached object from the database and make it persistent (Any modified fields will be refreshed);
2. session.update() causes the detached object to be persistent object and upon transaction commit, the database will be updated;
3. session.merge(), merge the changes, BUT, it is unclear whether it will update the database upon transaction commit and whether we can navigate the object graph.


Basically it says that the detached object will be persistent but not associated to the current session?

Does not persistent means:


Note: This is taken from
http://www.hibernate.org/hib_docs/v3/ap ... ang.Object)
http://www.hibernate.org/hib_docs/v3/ap ... ssion.html

IMHO, Open Session In View pattern is required instead of recommended for long conversation, or at least until the javadoc is updated.

There is a danger having a session opened for long period of time. The memory usage will keep increasing, because the object is never detached from the session. This means, session.evict() need to be called, or close and create a new session when it is clear to do so.

http://www.hibernate.org/hib_docs/v3/ap ... ang.Object)

And lastly, Session.disconnect() is required to free up jdbc connection to be used by other Thread.

Regards,
Edward

Thanks Edward,

In my case I'm doing a Session per Request. I don't need the session to span HTTP requests. In this scenario, I believe I want the session to be closed at the end of the Servlet Filter since leaving it open will cache things in memory and maintain the database connection.

Leaving the session open in the servlet won't guarentee that the next request that comes in will go to the same servlet thread and thus use the same session. Is this correct?

Thanks.

Just as a follow up, my comment above is based partially on this paragraph from the Hibernate 3 docs:



The Open Session In View pattern doesn't follow this. I understand from the previous reply that this is to keep from having to reattach objects, but since each servlet thread has it's own session you are not guarenteed that the next user request will get the session you previously used. Or am I missing something?

http://hibernate.org/42.html
http://hibernate.org/43.html

I've read those, but my question (or confustion) is with why the Servlet Filter would leave the Session open once the page has been rendered.

43.html has the two sections below which talk about Session closing and Transactions but they don't explain why the Servlet Filter never closes the Session. When the filter ends, the view has been rendered and the db transaction closed. Why does it stop at that point and not close the session?



Thanks!

I've never used it, but your hibernate config file can include the property
hibernate.transaction.auto_close_session
which closes the session when the transaction commits or rolls back.

You can guarantee to use the same session. I usually put the hibernate session inside HttpSession.

Regards,
Edward

What about a scenario where a request takes so long that the user makes another one, which obtains the Session from the HttpSession finishes earlier and disconnects the Session while the first one is still running.

e.g. A web page returns a list of results but only shows a sublist of them. The user then opens in a new tab every sublist. Some of them will most likely fail.

PS. Wow. I didn't notice the year of that post. Sat Apr 15, 2006.

I think that would be a problem as well. The servlet code would have to somehow handle knowing when to close the session if multiple requests come in. I'm not using that pattern in my apps so I don't have any direct experience with it.

Don

You need to synchronize concurrent threads accessing non-threadsafe data in the HttpSession. This is the same issue with any web application and there are various solutions you can find with Google. JBoss Seam has a built-in locking mechanism for that.

But if you just create a series of API's that:

1) open hibernate session
2) map hibernate objects to business objects (or vice versa)
3) Save if necessary
4) close hibernate session

You might open and close hibernate sessions several times per request, but the shorter hibernate session lifecycles seem to scale better (at the expense of being a little slower) and gives you complete control over hibernates behavior (like problems with saving a parent object and having children object attributes being saved as well).

Yes, but reattaching the detached instances can be a real pain. And a flury of transactions can put a nasty load on your database. You need to be careful.