Hi all,

I have a client -server app, they talk via EJB session beans. The client gets/sends domain objects from/to the server and only the server interacts with the DB via Hibernate.

The question is, how to retrieve lazy collections in the client?
Can I open a session, get lazy collection and close the session in the client? I suspect this will not work since only the server interacts directly with the DB :)

What other options are there?

Thank you very much. Any help is much appreciated!

--steve p.

I think this was discussed on a similar subject few days age. Have a look into the forum.

You're right, I asked the same question a few days ago, but I couldn't draw a conclusion :(

How can I retrieve lazy collections from my client?

Thanks to all.

There is no easy solution yet because this is a major issue in application design right now.

http://www.hibernate.org/Documentation/ ... chitecture

I just added a comment to that page about CarrierWave.

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

I'll add more about CarrierWave in the next days.

Thank you much, Christian. Can I hope the near future will bring up a solution to this problem? I believe this is crucial for Hibernate to work in a distributed environment ...

Many thanks again. All the best for Hibernate and Hibernate team!

--steve p.

I doubt WE will have the time to work on framwork. It is actually not a Hibernate problem, but a problem you will encounter in every distributed system with a rich domain model. It just happens that Hibernate users have those models and are very likely to run into this problem.

It's an area that needs more attentation by all people, so don't wait for anyone to find the perfect solution. Having said that, our Wiki would be a good place to sketch various approaches and discuss things like CarrierWave and SDO.

What are you tallking about. There is no "solution". This is a problem which must be handled by the application. Are we magicians?


The correct approach is to fetch all the data you need in the session bean before passing control back to the UI layer. This is easy and I have done it in more than one large application.

Its a much easier problem than the equivalent problem using CMP, which is to copy all the data onto DTOs.

Just a note: Gavin talks about the "lazy initialization" aspect of a bigger issue. He is of course right, thats the way to do it: Fetch all data you need before sending it to the UI tier.

A nice side-effect of an automated solution like CarrierWave would be faults for lazy loaded data, so there would be a mechanism for automatic lazy loading across tiers. But this is not the primary goal, just nice in some cases.

In fact, one of the things CarrierWave *does*, if I'm not mistaken, is just make it easier to specify exactly what data you need, so that it is all fetched in the first request to the session bean.

I agree with an automatic lazy loading mechanism across tiers.

thx,
--steve p.

If I fetch all data say for object A, this means I don't have lazy anymore.
If I want to get the lazy for A later in the GUI, do I have to make a special call to the session bean to retreive the specific lazy collection?
And how can I tell from the client if a collection was already loaded or not?



I agree with an automatic lazy loading mechanism across tiers.

thx,
--steve p.

I think you are thinking about this the wrong way.

You should NEVER keep object instances in the UI tier for more than a couple of requests. Otherwise that "cache" will become stale. If you write these kinds of applications, you should think more about using a distinct set of instances for "almost" every request. (I would reuse an object across perhaps two or three requests only.)

Think about what you would do if you had an application using entity beans/DTOs. You would *not* cache the DTOs in the UI tier for many requests. You would throw them away after one request, normally. Hibernate is just the same. We cannot magically disolve all the problems of multitiered architectures, we can only save you the pain of writing the extra DTO classes, and let you use the domain model itself for transfer of objects between tiers.

Do you have prior experience of servlet/DTO/SLSB/CMP architectures? If so, think about how things work in this architecture and apply it to Hibernate.

First, thanks Gavin [again] for your prompt response!



I don't have to worry about stale data. We have a messaging mechansim which triggers db refresh from the UI tier whenever something (meaningfull) changes in the DB.

I was hoping that I can reduce the calls to the session beans and (re)-using a rich domain object along with it's collections in the UI tier. But it looks like I have to poll the server each time I need to initialize a (presumably)lazy collection. Is this right?

Thanks in advance.

Pre-fetching all lazily initialized data is not a proper solution, since - as you stated - the data is really "lazy" anymore. If your application has a rich object model having huge number of associations, pre-fetching lazy collections can be a major performance issue.

Our example application is a group calendaring application running on Hibernate2, Struts 1.2 and Velocity 1.3. We are using the ThreadLocal-based design pattern for handling Hibernate sessions, so the session is kept alive for the lifespan of one HTTP request. However, sometimes we need to put data in the HTTP session for quick access and it introduces problems on objects which refer to lazily initialized collections. Here's one example use case:

1) User wants to perform an event search, trying to find all events occurring in February.
2) 186 events are matched, so the results must be paged. Application renders 10 results per page, which means that 19 result pages are created.
3) The result pages are stored in user's HTTP session for quick access, allowing the user to move to another result page quickly, since the action class won't need to perform the database search again.

Stale data is not a problem for us: if user decides to open one of the listed events, the event will be loaded from the database, and not picked from the memory-resident collection.

The event object contains references to three collections: attendees (users or groups), attachments and resources (like meetings rooms or vehicles). We certainly want to keep these collections lazy, because the overall amount of data loaded would be excessive otherwise. This wouldn't be a problem if we only needed to access the basic information of the event (such as event name, location, start date and end date), but we also need to perform fine-grained access control when we try to find out which actions user can perform on the event.

Access control introduces problems because the controller needs to access these lazily initialized collections in certain conditions. For example, in our access control policy a user can view event's details only if any of the following conditions are met:

1) User is the owner or the creator of the event
2) The event has public visibility
3) The event has attendee visibility and the user (or one of the groups the user belongs to) is on the attendee list of the event

If the controller falls back to condition 3, it needs to access the lazily initialized collection (event attendees). If this is performed on the result page number two, the controller throws an exception because Hibernate session is not alive anymore.

It is very likely that the user never browses to a result page beyond number two. Therefore it wouldn't make sense to pre-fetch these collections in advance, resulting in a huge object-graph to be loaded in and never being used. There must be a better alternative.