There are three types of inheritance models in Hibernate:

Table per class hierarchy
Table per subclass
Table per concrete class

 
 

Hibernate
Session–Cache or collection of loaded objects relating to a single unit of work

XDoclet Annotations used to support Attribute Oriented Programming

Defines HQL for expressing queries to the database

Supports Entity Relationships through mapping files and annotations in JavaDoc

Provides a Persistence Manager API exposed via the Session, Query, Criteria, and Transaction API

Provides callback support through lifecycle, interceptor, and validatable interfaces

Entity Relationships are unidirectional. Bidirectional relationships are implemented by two unidirectional relationships

EJB 3.0

Persistence Context-Set of entities that can be managed by a given EntityManager is defined by a persistence unit

Java 5.0 Annotations used to support Attribute Oriented Programming

Defines EJB QL for expressing queries

Support Entity Relationships through Java 5.0 annotations

Provides and Entity Manager Interface for managing CRUD operations for an Entity

Provides callback support through Entity Listener and Callback methods

Entity Relationships are bidirectional or unidirectional

 
 

Three types of instance states:

Transient -The instance is not associated with any persistence context
Persistent -The instance is associated with a persistence context
Detached -The instance was associated with a persistence context which has been closed – currently not associated

 
 

Callback interfaces allow the application to receive a notification when something interesting happens to an object—for example, when an object is loaded, saved, or deleted. Hibernate applications don't need to implement these callbacks, but they're useful for implementing certain kinds of generic functionality.


 
 

Hibernate uses a sophisticated algorithm to determine an efficient ordering that avoids database foreign key constraint violations but is still sufficiently predictable to the user. This feature is called transactional write-behind.

 
 

Automatic dirty checking is a feature that saves us the effort of explicitly asking Hibernate to update the database when we modify the state of an object inside a transaction.


 
 

A fetching strategy is the strategy Hibernate will use for retrieving associated objects if the application needs to navigate the association. Fetch strategies may be declared in the O/R mapping metadata, or over-ridden by a particular HQL or Criteria query.


 
 

Criteria is a simplified API for retrieving entities by composing Criterion objects. This is a very convenient approach for functionality like "search" screens where there is a variable number of conditions to be placed upon the result set.

dynamic-update (defaults to false): Specifies that UPDATE SQL should be generated at runtime and contain only those columns whose values have changed
dynamic-insert (defaults to false): Specifies that INSERT SQL should be generated at runtime and contain only the columns whose values are not null.

 
 

Mark the class as mutable="false" (Default is true),. This specifies that instances of the class are (not) mutable. Immutable classes, may not be updated or deleted by the application.


 
 

By mapping the property with access="field" in Hibernate metadata. This forces hibernate to bypass the setter method and access the instance variable directly while initializing a newly loaded object.