In the Spring Container the underlying persistence unit(oracle, mysql) used can be conveyed in three ways

  1. Dialect
  2. Vendor
  3. Provider

Using Dialect in Spring(or)application.xml

<bean id="jpaDialect" class="org.springframework.orm.jpa.vendor.HibernateJpaDialect"/>

<bean id="emf" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
    <property name="jpaVendorAdapter">
        <bean class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter" />
    </property>
....
</bean>

<bean id="transactionManager" class="org.springframework.orm.jpa.JpaTransactionManager">
    <property name="entityManagerFactory" ref="emf"/>
    <property name="jpaDialect" ref="jpaDialect"/>
</bean>

We are telling ‘Spring’ to configure a transactionManager whose properties are entityManagerFactory and jpaDialect. Since these properties have to be specific to hibernate these are set according. The entityManagerFactory and jpaDialect are now set specifically to hibernate (or Vendor).

Dialect and Vendor Adapter works together

Notes:

  1. transactionManager needs entityManagerFactory and jpaDialect
  2. entityManagerFactory – defines database related properties
  3. jpaDialect – JpaDialect is an interface encapsulates certain functionality that standard JPA 1.0 does not offer, such as access to the underlying JDBC Connection.

Using Vendor in Spring(or)application.xml

<property name="jpaVendorAdapter">
    <bean class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter" />
</property>

the VendorAdapter is injected in to transactionManager along with entityManager
Since you have provided the class as class=”org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter”/>, this allows Spring to plug in vendor-specific behavior into Spring’s EntityManagerFactory creators and it serves as single configuration point for all vendor-specific properties.It’s a custom implementation of spring’s own JpaVendorAdapter.

The reason it is so is the underlying database differs from application to application based on the needs and the underlying persistence unit which the developer would like to use I.E MySQL, Oracle.

Using Provider persistence-context.xml

org.hibernate.ejb.HibernatePersistence [/xml]

The tells spring to use the hibernate provider and the class org.hibernate.ejb.HibernatePersistence is Hibernate EJB3 persistence provider implementation.

Note:
Application works just by configuring persistence and provider because the vendor adapter is automatically passed by the persistence provided i.e. HibernatePersistence via the getPersistenceProvider in JpaVendorAdapter.

Provider + JpaVendorAdapter(Used getPersistenceProvider to get underlying Persistence technology in our case hibernate) -> Works
Dialect + JpaVendorAdapter -> Works
Provider + Dialect -> Doesn’t Works

Difference between configuring data source in persistence.xml and spring (or) application-context.xml files

persistence-context.xml

<persistence-unit name="LocalDB" transaction-type="RESOURCE_LOCAL">
    <class>domain.User</class>
    <exclude-unlisted-classes>true</exclude-unlisted-classes>
    <properties>
        <property name="hibernate.connection.driver_class" value="org.hsqldb.jdbcDriver"/>
        <property name="hibernate.connection.url" value="jdbc:hsqldb:hsql://localhost"/>
        <property name="hibernate.hbm2ddl.auto" value="create"/>
        <property name="hibernate.c3p0.min_size" value="5"/>
        ....
        <property name="hibernate.dialect" value="org.hibernate.dialect.HSQLDialect"/>
    </properties>
</persistence-unit>

application-context.xml

<bean id="domainEntityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
    <property name="persistenceUnitName" value="JiraManager"/>
    <property name="dataSource" ref="domainDataSource"/>
    <property name="jpaVendorAdapter">
        <bean class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter">
            <property name="generateDdl" value="false"/>
            <property name="showSql" value="false"/>
            <property name="databasePlatform" value="${hibernate.dialect}"/>
        </bean>
    </property>
</bean>

<bean id="domainDataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource" destroy-method="close">
    <property name="driverClass" value="${db.driver}" />
    <property name="jdbcUrl" value="${datasource.url}" />
    <property name="user" value="${datasource.username}" />
    <property name="password" value="${datasource.password}" />
    <property name="initialPoolSize" value="5"/>
    <property name="minPoolSize" value="5"/>
    .....
</bean>

If you are using persistence.xml you’re creating your own connection pool and do not profit from the existing connection pool in the container. Thus even if you configured your container to, say, a max of 20 simultaneous connections to the database, you can’t guarantee this max as this new connection pool is not restrained by your configuration. Also, you don’t profit from any monitoring tools your container provides you.

If you are using spring (or) application.xml
If you’re also creating your own connection pool, with the same disadvantages as above. However, you can isolate the definition of this spring bean and only use it in test runs.Your best bet is to look up the container’s connection pool via JNDI. Then you are sure to respect the data source configurations from the container.

What is PersistenceContext
A persistence context handles a set of entities which hold data to be persisted in some persistence store (e.g. a database).Entities are managed by javax.persistence.EntityManager instance using persistence context.Each EntityManager instance is associated with a persistence context. Within the persistence context, the entity instances and their lifecycle are managed.Persistence context defines a scope under which particular entity instances are created, persisted, and removed.
A persistence context is like a cache which contains a set of persistent entities , So once the transaction is finished, all persistent objects are detached from the EntityManager’s persistence context and are no longer managed

A Cache is a copy of data, copy meaning pulled from but living outside the database.Flushing a Cache is the act of putting modified data back into the database.
A PersistenceContext is essentially a Cache(copy of data from database outside database). It also tends to have it’s own non-shared database connection.An EntityManager represents a PersistenceContext (and therefore a Cache).An EntityManagerFactory creates an EntityManager(and therefore a PersistenceContext/Cache)

What is the difference between LocalContainerEntityManagerFactoryBean and LocalEntityManagerFactoryBean?

JPA specification defines two types of entity managers.

LocalEntityManagerFactoryBean LocalContainerEntityManagerFactoryBean
Entity Managers are created and managed by merely the application(“opening , closing and involving entity manager in transactions”) Entity Managers are created and managed by merely the J2EE container
creates a JPA EntityManagerFactory according to JPA’s standard standalone bootstrap contract creates a JPA EntityManagerFactory according to JPA’s standard container bootstrap contract.
Application-managed EntityManagers are created by an EntityManagerFactory obtained by calling the createEntityManagerFactory() container-managed EntityManagerFactorys are obtained through PersistenceProvider’s createContainerEntityManagerfactory()
LocalEntityManagerFactoryBean produces an application-managed Entity- ManagerFactory. LocalContainerEntityManagerFactoryBean produces a container-managed EntityManagerFactory

The only real difference between application-managed and container-managed entity manager factories, as far as Spring is concerned, is how each is configured in the Spring application context.

When to use JPA getSingleResult()
getSingleResult() is used in situations like: “I am totally sure that this record exists. I don’t want to test for null every time I use this method because I am sure that it will not return it. Otherwise it causes alot of boilerplate and defensive programming. And if the record really does not exist (as opposite to what we’ve assumed), it is much better to have NoResultException compared to NullPointerException. If the record is not found it throws NoResultException

When the JPA Entities will become detached

  1. When the transaction (in transaction-scoped persistence context) commits, entities managed by the persistence context become detached.
  2. If an application-managed persistence context is closed, all managed entities become detached.
  3. Using clear method
  4. using detach method
  5. rollback
  6. In extended persistence context when a stateful bean is removed, all managed entities become detached.

What is JPADialect
Dialect is “the variant of a language”.Speaking about Hibernate in context hibernate works with different databases.hibernate has to use database specific SQL. Hibernate uses “dialect” configuration to know which database you are using so that it can switch to the database specific SQL generator code wherever/whenever necessary

<bean id="jpaDialect" class="org.springframework.orm.jpa.vendor.jpaDialect"/>

Now in the above statement I have specified that the jpaDialect I am going to use is of Hibernate Variant of implementation for JPA and Spring needs to take this into consideration
while creating entityManagerFactory.

The way it is referred is as follows

<bean id="transactionManager" class="org.springframework.orm.jpa.JpaTransactionManager">
    <property name="entityManagerFactory" ref="entityManagerFactory"/>
    <property name="jpaDialect"  ref="jpaDialect"/>
</bean>

Why we need JPAVendorAdapter
EntityManagerFactory manages the lifecycle of the entities.Persistence Provider is the one which specifies the details about the database and connection details of the underlying database either by persistence-context.xml or by injecting instances of EntityManager using @PersistenceContext annotation. JPAVendorAdapter helps to define the persistence context which is likely to be used.

Persistence-context.xml

  <persistence-unit name="MyPersistenceUnit" transaction-type="RESOURCE_LOCAL">
        <provider>org.hibernate.ejb.HibernatePersistence</provider>
        <non-jta-data-source>java:comp/env/jdbc/ooes_master</non-jta-data-source>
        <properties>
        	<property name="hibernate.dialect" value="org.hibernate.dialect.MySQL5Dialect"/>
        	<property name="hibernate.show_sql" value="true"/>
        	<property name="hibernate.hbm2ddl.auto" value="update"/>
            <property name="hibernate.cache.region.factory_class" value="net.sf.ehcache.hibernate.SingletonEhCacheRegionFactory"/>
            <property name="hibernate.cache.use_second_level_cache" value="true"/>
            <property name="hibernate.cache.use_query_cache" value="true"/>
        </properties>
 </persistence-unit>

If we want to inject instances of EntityManager using @PersistenceContext annotation, we have to enable annotation bean processor in Spring configuration

<bean class="org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor" />

Usually this line is optional because a default PersistenceAnnotationBeanPostProcessor will be registered by the and XML tags.

getSingleResult() return detached or Managed Object
objects returned from .getResultList() are managed.When you made changes on the managed objects, you do not worry about merging as those changes will be picked up by the EntityManager automatically.The managed objects will become detached when the EntityManager that is used to load that object is close(), clear() or detach(). Detached objects are not manged anymore and you should do merging to let the EntityManager pick up the changes.