Keep the Session open for one request, close it when all business logic in that thread has been executed. This is the common pattern, see:

http://www.hibernate.org/168.html

Use a call Interceptor (this can even be a Servlet filter) to do this, the pattern is called "Open Session in view". No, this doesn't create a dependency between the Presentation and the Persistence layer, it's a function of the global System layer that manages resources.

The Session is also the first-level cache. Whenever you load()/get() or navigate an object, it gets added to that cache. You will end up with lots of stale data if you re-use the same Session for a long time. A single Session is a single Unit-of-Work, and usually has the same scope as a single database transaction.

Long and disconnected Sessions are definitely an advanced case and not for the beginner still struggling with the basic scopes.

This is the third question in two days about "can we just open a new Session" whenever we access a proxy. No, we won't do it and you shouldn't. Think about it: Your transaction semantics would be ad-hoc: When do we close the second new Session? After lazy loading a single proxy? This second Session of course also opens a new database transaction: Is the original object still there? What do we do if it has been deleted?

This opens a can of worms you (and we) can't control. Just take care you retrieve the right amount of data you need for a use case. Lazy loading accross tiers just doesn't work.

I understand the "Open Session in view" pattern when used in Web environment where you have nicely one thread serving each request/response.

Now I'm more interested in how to apply this pattern in normal desktop application which uses the same thread of control all the time. From christian's answer I understood that it is not propably wise to create a Session in the start of the program and end it in the end.

On the other hand, if in the beginning of the application I create a UI component that is shown the whole life span of the application and it needs lazily initialized domain objects, the "Open Session in view" pattern when directly applied would mean that the Session for that UI component would be created in the beginning of the app and closed in the end of the app.

Now the question is that does anyone know any nice pattern to use hibernate in normal desktop app or should I try to write my desktop app in a way that request/response model of the Web world would fit in it and then use this "Open Session in view" pattern as it is used in the Web apps?


Sincerely,

Jouni Hartikainen

Jouni,

Your example is exactly how I discovered the session problem (in unit tests). I think that my set of design challenges are a bit different than most Hibernate integrations in that I am working on integrating Hibernate with an existing application framework, and cannot predict in advance how users of the framework will need to interact with persistence.

After giving the issue some thought yesterday I think I have come up with an alternate approach. Rather than strictly following the session recommendations that the Hibernate documentation recommends, I'm leaning towards a solution that allows an end user of the framework to configure how sessions will be used. In cases where they want to use lazy initialization they will need to indicate that sessions should remain open beyond individual (or small sets) of transactions.

In reference to the possible issue of memory creep for long lived sessions, I will most likely want some sort of daemon process to periodically purge the session (second level cache will eliminate redundant requests). Or, if there is a way to turn off the session level caching, that should solve the problem as well.

Jonathan House

Jouni, Jonathan

I seem to have the same problem. See thread:

http://forum.hibernate.org/viewtopic.php?t=927886

My DAO now does the following:



and in Order :



This should also work in a Desktop App without servlet filters or the like...
The disadvantage seems to be that the master object hits the database once (is reloaded) on each access to getOrderItems();

sorry,

class Order should look like

public getOrderItems() {
if (!dao.isInitialized(orderItems))
dao.reload(this, orderItems);
return orderItems;
}

It can, but that is not a sticking factor at this point. When you are building a specific application you will know when it makes sense to keep sessions open for specific types of business objects, and transactional for others.

The challenge I am facing is the fact that Hibernate is being used as a generic persistence agent in an application framework that is intended to be used by other developers. This is not a trivial framework in that it encompasses more than just a presentation layer ('ala Struts) or rule management (Drools), etc.

The specific challenges that I am seeing are situations where Hibernate provides functionality that is also part of my framework (state management, object creation, object reference integrity, etc). Since Hibernate is only one possible persistence option I am in a position where I have only limited flexibility to modify how the framework operates in order to get a smooth integration with Hibernate. So things like on/off switches and places where I can hook into Hibernate functionality to do things are of more importance to me than someone doing a specific vertical application.

Christian, thank you for your feedback on this topic. Please bear in mind that although I may be a beginner at the Hibernate API, I am not a beginner at O/R mapping functional issues. I wrote an article discussing the challenges of O/R mapping 6 years ago when the company I was working for created their own proprietary O/R mapping solution.

In summary, I believe that I have the answer to my question, which is that there is not a readily available hook in place that will allow me to perform work in the middle of the lazy initialization process.

Thanks to everyone who participated in this conversation, and I am looking forward to the next discussion.