Hi,

I'm quiet challenged by the idea of lazy fetching, especially in certain cases. I hear people saying to always use lazy fetching, and Hibernate 3 comes with lazy fetching true by default.

To me, lazy fetching is just a way of postponing the query execution a little longer.. maybe to another method.. but the query has to be executed to fetch the data.

If I have a scenario where-in I am sure that all the objects in my object graph will be used at some point within the application flow, should I be using lazy initialization, and leave my session open for long periods? I think it's better to fetch all the objects in the DAO itself, rather than postponing it to some other later, as I am damn sure that I require all the objects within the structure. In that case, I suppose, it's wise to go for non-lazy initialization.

Lemme know your thoughts on this.

--
Sam.

Yes, I also agree to that. So in your case it makes perfect sense to avoid lazy loading. However in many scenarios, lazy loading makes sense where we dont know if say a collection would be required or not.

Don't know how long your application flow is, but if you use lazy fetching (and transatction isolation to read-comnitted) you will get the data as it is on the moment of fetching.
Might be different if you use lazy and the fetch takes place at a later time and someone else committed data. (different user). Your non-lazy fetch might then be stale data!

Well.... In my flow, i'm pretty sure nobody else will update the data between two requests. So, there's no scenario where-in another flow will update the same data.

Hello,

We also have use cases in our application in which we know up front that many of the objects will need to be loaded and some updated to peform the function.

I am planning to still define the entities with lazy fetching since loading the entire object graph is not always required. In those cases where this is required, I will define DAO queries to fetch the required objects.

Regards,
Kurt