Hi!

We have started to work on application with a DAO layer where Hibernate is used to persist the data. The data model is comprised of several Java objects like Flight, Hotel, Reservation, Customer, ... and they have been mapped to a database with Hibernate. The data model is accessed by different software packages and we do not know which objects/properties these packages are accessing.
This is the point were we now ran into problems with Hibernate. The problem is that lazily loaded objects/collections cannot be loaded once a session was closed. As stated in the Hibernate manual, there are only two ways to deal with that: either load all entities eagerly or guarantee that all necessary collections/properties have been loaded properly before returning them. We cannot use eager loading, since the data model is huge and we do not want to load a huge portion of the database when an object is accessed only to guarantee that all values are initialized correctly. We also cannot lazily load the required properties/collections of an accessed object, since we do not know which properites/collections a software package is going to use.

Now my question: is it generally not possible to implement such a scenario with Hibernate (where no assumptions on the data access pattern can be made)? I have seen that there have been some postings on this issue, especially in the context of rich client applications, but I did not find a real answer to that problem. Can it be that Hibernate is that inflexible and only tailored at specific usage patterns supported by its Session model?

thanks, iS

You're forgetting that hibernate is a tool to access the database. It can do anything. It won't automagically load exactly what you want perfectly by repeatedly calling the load command.

You can reassociate a disconnected bean to any session and get more of its related data.

You'll probably have to create some custom methods and queries to access the various kinds and amounts of data you'll need.

One solution is to use the long life EntityManager pattern.

In this pattern, do not create and close an EntityManager for each transaction, instead create and use one EntityManager per thread (EntityManager's are not thread safe).

Then you can access more data in lazily loaded fields at any time (as long as the EntityManager for the object remains open).

The logic to manage one EntityManager per thread is available as utility classes in the Spring framework. Alternatively, write your own - I have done so - it's not that hard.

With regards to performance. I used to Kodo JDO, in that ORM implementation you could specify the number of rows to fetch at a time for lazily loaded fields. I don't know if the same feature is available in Hibernate - I've never looked.

The reason I've never looked is because if I have a large List then I write a query to page through it as required by the client, rather than accessing the whole List (with lazy loading) as part of some object graph.

If you have a large object graph, your approach, of loading the graph, and doing updates on it, then calling merge, will be very slow compared to the other more efficient approach of writing custom queries to fetch, update, and delete just the data you need.

Andy.