We are looking at using Hibernate for a large system, and a concern has been raised around the potential negative performance impact of lazy loading.

Lazy loading obviously is a very beneficial concept, but I suspect that if you know you need an object and its related objects that use lazy loading would be slower than issuing a single select statement that joins the tables containing the data.

So, for instance, if I had an Account object that has a collection of Transaction objects -- I could load an Account with a collection of Transaction objects using a join. Or, I could load the Account and when I try to use the Transactions it would go back to the database and retrieve them.

Has anyone done any analysis of the performance difference (in the situation where you need both objects)? I am interested in how costly the extra trip to the database is and whether it should be a concern.

BTW: I know we can do joins with Hibernate while still supporting lazy loading, but I am more concerned about it because sloppy developers (we will have a lot of developers) might not use joins where it makes sense, instead relying on the lazy loading to give them what they need -- I am interested in whether this could become a performance problem.

Thanks!

Randy

It is allways a tradeof of result set size versus multiple queries, there is no definite answer, all depends on your use case. Note however that you most likely must do lazy loading at some point in the object graph, otherwise you quickly get into situations where the complete object graph is fetched for every load due to non-lazy associations.

For sloppy developers: Note that you can use outer-join="true" in the mapping file, to force join loading for certain associations.

Much more important, Hibernate supports both lazy and eager loading not only with "defaults" in the mapping metadata, but can efficiently do both at runtime. You can control the graph of objects that should be fetched at a very fine grained level.

And note that we can't obviously do much about developers not using the the appropriate options ;)

I agree christian, using sloppy developpers and wanting advanced Hibernate usage is a bit hard. Having an Hibernate expert in the team, is the solution I use.

Otherwise, use the 80%-20% rules to choose the best static mapping/

I agree with this. If you seperate data access code into DAOs, it should be easy for the "data access / Hibernate expert" to come along later and tune the queries and mappings. Its actually an advantage of ORM that performance is "easy" to adjust at a late stage of development.