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

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

Spring, AOP and Hibernate: Understand Spring

Advantages of layered (multi-tier) architecture :

• Improved modularity and reuse 
• Simplifies development
• Simplifies testing

Layers are essential because they separate some concerns such as presentation and business logic. But without the business tier, there are concerns that are not easily separated. They are called cross cutting concerns such as transactions, security, persistence, logging, etc.
These cross cutting concerns span multiple application components and they must be implemented by sprinkling code throughout the application.

What is Spring

It is a framework for simplifying Java EE plateform application development and enforce the respect of multi-layered development.
By using spring, the code is supported by a backbone that handles dependency wiring, provides aspect-oriented programming (AOP) capability, and generates cohesive configuration metadata that implicitly documents the way your application's pieces fit together.
Spring has enabled the externalization of integration details to an XML configuration file or to express dependency injection through Java annotations.
The mission of spring was first to make the development of Server-side Java applications simpler. It offered a better solution to wiring application dependencies together. For this reason, Spring is often referred to as a Container, meaning that it offers a centralized abstraction for integrating collaborating dependencies via configuration, rather than writing code to handle this task.
Spring's job is to parse your configuration files and then instantiate your managed classes, resolving their interdependencies. The BeanFactory interface defines the core Spring engine that englobe your beans and wires the collaborating dependencies together.
The ApplicationContext extends the BeanFactory interface, providing a set of more robust features. Spring ships with a listener that you can throw into your web.xml file to automatically bootstrap the Spring ApplicationContext and load your configuration file.

Beyond its original IoC roots, Spring provides a pluggable transactional management layer, AOP support, integration points with persistence frameworks, and a flexible web framework called Spring MVC.

Persistence Layer- Spring Hibernate:

The persistence layer often serves as the foundation upon which an application is built. Spring helps to enforce a modular architecture in which the persistence tier is devided into several core layers that contain the following components: 

• The domain model
• The Data Access Object (DAO) layer
• The service facade (or Service Façade)

The domain model represents the entities within an application, defining the manner in which they relate to one another. Each class within the domain model contains the various properties and associations that correlate to columns and relationships within the database.

The DAO layer defines the means for saving and querying the domain model data. The goal of the DAO pattern is to completely abstract the underlying persistence technology and manner in which it loads, saves, and manipulates the data represented by the domain model. The key benefit of the DAO pattern is separation of concerns- the lower-level details of the persistence technology and datasource are abstracted into a series of methods that provide querying and saving functionality. If the persistence technology changes, most of the necessery change would be limited to defining a new DAO implementation, following the same interface. Defining DAO methods in a separate interface is crucial, as it decouples the purpose and contract of the DAO from the actual implementation. Of course, the DAO implementation class will use Hibernate, JPA or whatever persistence technology we have chosen to employ. However, the higher layers of the application are insulated from these details by the DAO interface, giving us portability, consistency, and well-tiered architecture. 

The layer that handles the application business logic is called the Service layer.  It defines an application's public-facing API, combining one or more lower-level DAO operations into a single, cohesive transactional unit. Service facade methods group together multiple DAO methods to accomplish business logic as a single unit of work: this is the concept of a transaction. 

In Spring, the service layer typically is intended to accomplish three primary tasks:

• Serve as the core API throught which other layers of your application will interface
• Define the core business logic, usually calling on one or more DAO methods to achieve this goal
• Define transactional details for each facade method  

Dependency Injection in Spring:

Spring has become the facto standard for integrating disparate components and frameworks, and has evolved far beyond its dependency injection roots. The purpose of dependency injection is to decouple the work of resolving external software components from your application business logic.

Spring is a lightweight IoC container, meaning that it will assume the responsibility of wiring your application dependencies. Spring allow to tie components together in a loosely coupled manner. This has far-reaching efforts for any application, as it allows code to be more easily refactored and maintained.

Aspect Oriented Programming AOP:

AOP is a strategy that allows behavior to be injected into code in places across an application (a whole slew of classes). The functionality that we would like to apply across the series of classes has little to do with the main purpose of those classes.
Spring ships with transactional support that can be applied to application code through the use of interceptors that enhance your service layer code. An interceptor is code that can be mixed into the excution flow of a method, usually delegating to the interceptor befor and/or after a particular method is invoked. The interceptor encapsulates the behavior of an aspect at a point in a method's execution.

At the basic level, Spring accomplishes AOP through the use of the proxy design pattern.

When you advise your classes by injecting cross-cutting behaviour into various methods, you are not actually injecting code throughout your application (although in a way, that is the net effect of using AOP). Rather you are requesting that srping create a new proxy class, in which functionality is delegated to your existing class along with the transactional implementation.

When you weave cross-cutting behavior into your classes via AOP, Spring is not directly inserting code; rather, it is replacing your classes with proxies that contains your existing code intertwined with the transactional code. Now applying transactional behaviour to a service layer class is a matter of specifying the @Transactional annotation at either the class or method level.

Biblio:
- Book: Spring persistence with Hibernate, Paul Tepper Fisher and Brian D.Murphy