Hibernate, JPA Interview Questions : Definition, JPA life cycles, Concurrency, Caching

Removed

About Hibernate and JPA

Today, I will explain some of Object Relational Mapping terms. Hope that it will be helpful and clear for you. Let's start by explaining what is hibernate.  ORM frameworks provide an abstraction layer over the persistence technology (relational databases like Oracle, MySQL...), allowing developers to focus on the object-oriented details of their domain model rather than lower-level database concerns. JPA is a specification of ORM and Hibernate is just one of many projects that provide an implementation of that specification. It provides an enterprise-level solution for building a persistence tier.

Hibernate framework defines the ways in which the tables and columns of a database are synchronized with the object instances and properties of JavaBeans (the created Entities).

The 4 key interfaces in any JPA application are:

• The EntityManagerFactory: which represents the configuration for the database in the application.
• The Entity Manager: It is analogous to a database connection and used to access a database in a particular unit of work. It is used to create and remove persistent entity instances, to find entities by their primary key identity, and to query over all entities.
• Entity Transaction
• Query

- Unit of work: The most common pattern in a multi-user client/server application is entitymanager-per-request. In this model, a request from the client is send to the server (where the JPA persistence layer runs), a new EntityManager is opened, and all database operations are executed in this unit of work. Once the work has been completed (and the response for the client has been prepared), the persistence context is flushed and closed, as well as the entity manager object. You would also use a single database transaction to serve the clients request.

- This is the default JPA persistence model in a Java EE environment; injected (or looked up) entity managers share the same persistence context for a particular JTA transaction.

- Persistence Context is a set of entity instances in which for any persistent entity identity there is a unique entity instance. With the persistence context, the entity instances and their lifecycle is managed by a particular entity manager. The scope of this context can either be the transaction or an extended unit of work.

Life Cycle of a JPA Entity

 There are 5 key states that an entity might be in:

• New / Transient: An object is instantiated but not yet associated with an Entity Manager and has no representation in the database.
• Managed / Persisted 
• Detached: Detached entity objects are objects in a special state in which they are not managed by any EntityManager but still represent objects in the database. Detached objects are often returned from a persistence tier to the web layer where they can be displayed to the end-user in some form. Changes can be made to a detached dobject, but these changes won't be persisted to the database until the entity is reassociated with a persistence context (the entity is merged back to an EntityManager to become managed again).
• Removed

- The merge method's major task is to transfer the state from an unmanaged entity (passed as the argument) to its managed counterpart within the persistence context.
- merge deals with both new and detached entities. Merge causes either INSERT or UPDATE operation according to the sub-scenario (on the one hand it is more robust, on the other hand this robustness needn't be required.)
- persist always causes INSERT SQL operation is executed (i.e. an exception may be thrown if the entity has already been inserted and thus the primary key violation happens.) 

Query Languages 

- HQL (Hibernate Query Language) and JPQL (Java Persistence Query Language) both offer an object-oriented syntax for expressing query that is very similar to SQL. The two languages are interpreted at runtime, which means you cannot use the compiler to verify the correctness and integrity of a query. To adress this limitation, Hibernate includes a Criteria API, which allows queries to be expressed programmatically.

Loading in Hibernate 

- Say you have a parent and that parent has a collection of children. Hibernate now can "lazy-load" the children, which means that it does not actually load all the children when loading the parent. Instead, it loads them when requested to do so. You can either request this explicitly or, and this is far more common, hibernate will load them automatically when you try to access a child.

Lazy-loading can help improve the performance significantly since often you won't need the children and so they will not be loaded.
Also beware of the n+1-problem. Hibernate will not actually load all children when you access the collection. Instead, it will load each child individually. When iterating over the collection, this causes a query for every child. In order to avoid this, you can trick hibernate into loading all children simultaneously, e.g. by calling parent.getChildren().size().

- The fetching strategy is declared in the mapping relationship to define how Hibernate fetch its related collections and entities. There are four fetching strategies

•  fetch-”join” = Disable the lazy loading, always load all the collections and entities.

• fetch-”select” (default) = Lazy load all the collections and entities.

• batch-size=”N” = Fetching up to ‘N’ collections or entities, *Not record*. The batch-size fetching strategy is not define how many records inside in the collections are loaded. Instead, it defines how many collections should be loaded.

• fetch-”subselect” = Group its collection into a sub select statement.

Caching levels in Hibernate:

-  Caching is all about application performance optimization and it sits between your application and the database to avoid the number of database hits as many as possible to give a better performance for critical applications.
- The first-level cache is the Session cache and is a mandatory cache through which all requests must pass. The Session object keeps an object under its own power before committing it to the database.
- Second level cache is an optional cache and first-level cache will always be consulted before any attempt is made to locate an object in the second-level cache. The second-level cache can be configured on a per-class and per-collection basis and mainly responsible for caching objects across sessions.

Transactions:

- Transaction is based on ACID:

• Atomicity: If  one step fails, all the other steps fails
• Consistency: works on a consistent set of data that are hidden from other concurrency running transactions. So, data are left in a clean and consistent state after completion
• Isolation: Allows different users to work concurrently with the same data without compromise its integrity and correctness. A particular transaction should not be seen by other concurrently running transactions
• Durability: Persistent changes should not been lost even if the system fails.

- Java transaction API (JTA) specifies standard Java interfaces between a transaction manager and the parties involved in a distributed transaction system: the resource manager, the application server, and the transactional applications.

Concurrency Management in Hibernate

- Concurrency management is done through Pessimistic or Optimistic way. While the application might concurrently access the "same" (persistent identity) business object in two different persistence contexts, the two instances will actually be "different" (JVM identity). Conflicts are resolved at flush/commit time, using an optimistic approach (automatic versioning).

- Hibernate Entity Manager directly uses JDBC connections and JTA resources without adding any additional locking behavior. Hibernate Entity manager adds automatic versioning but dos not lock objects in memory or change the isolation level of the database transaction.

-The only approach that is consistent with high concurrency and high scalability is optimistic concurrency control with versioning. Version checking uses version numbers, or timestamps, to detect conflicting updates (and to prevent lost updates). Hibernate provides for three possible approaches to writing application code that uses optimistic concurrency:

•  Application version checking
• Extended entity manager and automatic versioning
• Detached objects and automatic versioning

 
Biblio:
- http://www.objectdb.com/java/jpa/persistence/detach
- http://spitballer.blogspot.fr/2010/04/jpa-persisting-vs-merging-entites.html
- http://courses.coreservlets.com,  Transaction Management and Automatic Versioning
- http://docs.jboss.org/hibernate/orm/4.0/hem/en-US/html/transactions.html
- Book: Spring persistence with Hibernate, Paul Tepper Fisher and Brian D.Murphy