MaheshS Kumbhar wrote:I read the following sentence on http://docs.jboss.org/hibernate/core/3.3/reference/en/html/performance.html#performance-fetching
Select fetching: a second SELECT is used to retrieve the associated entity or collection. Unless you explicitly disable lazy fetching by specifying lazy="false", this second select will only be executed when you access the association.
That means, fetch=select is doing the same thing what lazy=true does. Then what is the need of fetch=select attribute?
Guide me if I have taken the concept wrong.
Mahesh
Each configuation is doing something very different than the other. Specifying a relationship as Lazy does mean that requested are pulled by a separate select. However, configurating the fetch as Select has wider implications that can really impact performance. Consider an object that has a non-Lazy relationship to 5 other objects. If you retrieve the object you will have one select statement for the objects and 5 more select statements to retrieve each of the related objects. This is not so bad if your first statement was for a specific object. However, if your first statement returned 100 objects then it will take 500 more query statements to retrieve all of the related objects. If you set fetch="join" then Hibernate will attempt to retrieve the object and its related objects in one SQL statement that joins all of the tables in which the objects are stored. In the best case, Hibernate is able to execute a single SQL statement to get all of the data it needs to build the requested objects.
If your objects are going to be passed outside of the context of your Hibernate, such as from an
EJB container to a Sevlet container, then you MUST set Lazy="false" or you will encounter errors when you access the related objects. In most cases if Lazy is set to False then you want to set fetch="join".