DAO


An entity is essentially a noun, or a grouping of state
associated together as a single unit. It may participate in relationships to any number of other entities in a number of standard ways. In the object-oriented paradigm, we would add behavior to it and call it an object.

Characteristic of entity :
-Persistability
-Identity
-Transactionality
-Granularity

From IBM

When you performance-tune Hibernate applications, you’ll spend the most development time tweaking how Hibernate deals with entity relationships. You’ll want to minimize the amount of data pulled into the application and at the same time minimize the number of queries that need to be executed. Hibernate gives you two main ways of dealing with relationships: lazy fetching and eager fetching.

Lazy fetching

Lazy fetching minimizes the amount of data queried from the database. Instead of querying all data from an association when an object is loaded, queries for associations marked as lazy are deferred until that association is actually used. For example, the Employee object has an Address object associated with it. Whenever an Employee is loaded, Hibernate does not automatically load the Address because the association between these objects is lazy. Instead, when the Employee object is loaded, Hibernate creates a proxy instance of the Address. When accessed for the first time, the proxy asks the Hibernate session to query the Address object and then defer all future calls directly to the queried instance. If the Address object is never used during the Employee object life cycle, then the Address query never needs to execute. Using this feature ensures that Hibernate loads the data only when it is needed.

Lazy fetching should almost always be used as your default association-fetching strategy. Real-world object models have large numbers of highly complex object associations; not using lazy evaluation could easily result in the entire database being loaded into the session any time a single object is loaded. Enabling lazy evaluation is simple but varies slightly depending on the association type. Collection-based associations (OneToMany and ManyToMany) are set to lazy evaluation by default, so no configuration is necessary to benefit from lazy evaluation. Single-object associations (OneToOne and ManyToOne) are not lazy by default. To use lazy evaluation with these associations, specify it on the association’s annotation:

@ManyToOne(fetch=FetchType.LAZY)
public void getAddress() {

Lazy mapping and HBM format

Implementing lazy mapping is slightly different when you use Hibernate’s HBM format, instead of annotations, to define your mappings. Since version 3.0, for any type of association defined using HBM files, the default fetching strategy is lazy fetching. No additional configuration is necessary even for single-object associations.

Issues with lazy fetching

Although lazy fetching should be the primary fetching strategy for most applications, it does add a few complications. The most serious is the LazyInitializationException. A lazy association can be traversed (and the associated entity retrieved) long after its parent object was initially loaded. However, to query the association’s data, the Hibernate session needs to be available and attached to a database connection from the pool. This error can occur if the Hibernate session and associated database connection is closed after the object was retrieved, but before the association was accessed. Hibernate throws a LazyInitializationException because the query is executed for the lazy association, and no connection to the database is associated with it. Many strategies for dealing with this issue are available, but that topic is beyond this article’s scope (the “Open Sessions in View” entry in Resources links to a relevant discussion).

Another issue to consider is how many queries are executed when traversing lazy associations. The first time an instance of a lazy association is traversed, a query is executed. This isn’t much of an issue with single instances of objects, but iterating over lists of objects can easily cause a large number of queries to be executed. Consider an example of a program that prints out the address associated with 10 employees. By default, if lazy fetching is used, 11 queries will be executed — one for the list of employees and one for each employee’s address. This obviously can lead to serious performance issues. The problem is common enough to have been given its own name. Hibernate calls this the n+1 Selects Problem. (Martin Fowler calls it ripple loading.).

Eager fetching

Eager fetching is essentially the opposite of lazy fetching. When an object is loaded, any associations marked as eager are immediately loaded as well. When a single object is loaded, no fewer queries are run than if lazy association is used. But because the query runs immediately, there’s no chance of a LazyInitializationException. Eager evaluation can also help with the n+1 Selects Problem. If the Employee object’s Address association is eager, and a query is executed to retrieve ten Employee instances, two queries will fire: one for the list of Employee instances and one for a list of Address instances associated with the Employee objects. Hibernate then seamlessly merges these lists together.

As a default, eager fetching is probably not a good idea. If you use it too frequently, it’s easy to load large trees of unneeded data. But sometimes an association is always needed, in which case working with eager evaluation can make sense. Enabling eager fetching is essentially the same process as enabling lazy fetching. Simply specify it on the annotation:

@ManyToOne(fetch=FetchType.EAGER)
public void getAddress() {//...}
public interface GenericDAO<T, ID extends Serializable> {
 
    T findById(ID id, boolean lock);
 
    List<T> findAll();
 
    List<T> findByExample(T exampleInstance);
 
    T makePersistent(T entity);
 
    void makeTransient(T entity);
}