createQuery() createSQLQuery() createCriteria()
Creates Query Object Creates Query Object Creates Criteria Object
Uses HQL Syntax Uses DB Specific Syntax Uses Entity Class
The Columns of the rows retrieved would be name of the POJO Model Class The Columns of the rows retrieved would be name of Native DB fields Create sql query using Criteria object for setting the query parameters
CRUD operation could be done CRUD operation could be done Only Read Operation is allowed
Supports Interoperability between different DB’s Does not support Interoperability since the query format should be changed when the DB is changed Supports Interoperability between different DB’s
Does not work without Model Class Bean with columns of Table alone is Enough.No need for Entity class generation Does not work without Model Class
No need for mapping between Entity class object and Table Columns The Bean Objects should be mapped with table Columns No need for mapping

createQuery – session.createQuery()

------------------------------------------------------
**DB_TBL_Col(tblEmployee)**| **POJO(Employee)**
EMP_ID                     | employeeID
------------------------------------------------------
Query query = session.createQuery("from Employee E where E.employeeID = 'A%'");
List<Person> persons = query.list();

The below batch script helps to read the selected trailing lines from Log File

@echo off
cls
setlocal EnableDelayedExpansion
set "cmd=findstr /R /N "^^" C:\Users\Mugil\Desktop\test.txt | find /C ":""

for /f %%a in ('!cmd!') do set totalLines=%%a
rem echo "totalLines-"%totalLines%


@set linesToConsider=4
set /a lineToStart="%totalLines%-%linesToConsider%" 

rem echo "lineToStart-"%lineToStart%

set content=
for /f "skip=%lineToStart% delims=" %%i in ('type C:\Users\Mugil\Desktop\test.txt') do set content=!content! %%i


@echo "content - "%content%


If NOT "%content%"=="%content:SUCCESS=%" (
    echo Build Successful
) else (
    echo Build Failed
)

pause

Working with EntityManagerFactory – Best Practices

  1. EntityManagerFactory instances are heavyweight objects. Each factory might maintain a metadata cache, object state cache, EntityManager pool, connection pool, and more. If your application no longer needs an EntityManagerFactory, you should close it to free these resources.
  2. When an EntityManagerFactory closes, all EntityManagers from that factory, and by extension all entities managed by those EntityManagers, become invalid.
  3. It is much better to keep a factory open for a long period of time than to repeatedly create and close new factories. Thus, most applications will never close the factory, or only close it when the application is exiting.
  4. Only applications that require multiple factories with different configurations have an obvious reason to create and close multiple EntityManagerFactory instances.
  5. Only one EntityManagerFactory is permitted to be created for each deployed persistence unit configuration. Any number of EntityManager instances may be created from a given factory.
  6. More than one entity manager factory instance may be available simultaneously in the JVM. Methods of the EntityManagerFactory interface are threadsafe.
Posted in JPA.
public class Test 
{
    private static final Map<Integer, String> MY_MAP = createMap();

    private static Map<Integer, String> createMap() {
        Map<Integer, String> result = new HashMap<Integer, String>();
        result.put(1, "one");
        result.put(2, "two");
        return Collections.unmodifiableMap(result);
    }
}

Unidirectional – bidirectional relationship provides navigational access in one direction

  Parent -----> Child

i.e you can go from parent to child, but you cannot go back from children to parent.

However, if there were no pointer to Parent in Child:

class Child { }

Bidirectional – bidirectional relationship provides navigational access in both directions

  Parent <-----> Child

i.e you can go from a Parent to its child, and vice-versa: the parent knows about its child, the child knows about its parent

class Parent {
  Child* children;
}

class Child {
  Parent* parent;
}

Idle Scenarios
One to One unidirectional Mapping
employee knows the employer

One to One Bidirectional Mapping
employer knows the employee and employee knows the employer

One to Many unidirectional Mapping
employee has a skill in his skill set which is not used by other employees

One to Many bidirectional Mapping
employee has a skill in his skill set which is not used by other employees and
employer knows that employee has this skill in skill set

Many to One unidirectional Mapping
employees knows which employer he is going to work but employer has no idea about employee

employees will have employerId in their entity class but employer has no details of employee

Many to One bidirectional Mapping
Many employees work for one Employer. The employer knows about employee and employee knows about employer

employees will have employerId in their entity class but employer will have empid of employee

Many to Many unidirectional Mapping
Employee knows the employers he has worked for but employers does not know details of employee who worked for them

Many to Many bidirectional Mapping
Employee knows about the employers he has worked for and employers knows about employee who has worked for them.

JPA COUNT returns a Long
When extracting the count from the table JPA returns long based on the type of query used.

JPQL

Query query = em.createQuery("SELECT COUNT(p) FROM PersonEntity p " );
query.getSingleResult().getClass().getCanonicalName() --> java.lang.Long

Native Query

Query query = em.createNativeQuery("SELECT COUNT(*) FROM PERSON");
query.getSingleResult().getClass().getCanonicalName() --> java.math.BigInteger

If it is Native Query big Integer is returned or if it is JPQL then Long is returned.

So before assigning to Integer the value should be typecasted.

 int count = ((Number)arrCount.get[0]).intValue();
 System.out.println(count);

Needs to be Removed

<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:context="http://www.springframework.org/schema/context"
	xmlns:tx="http://www.springframework.org/schema/tx" xmlns:jpa="http://www.springframework.org/schema/data/jpa"
	xsi:schemaLocation="http://www.springframework.org/schema/beans
   http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
   http://www.springframework.org/schema/context
   http://www.springframework.org/schema/tx
   http://www.springframework.org/schema/data/jpa http://www.springframework.org/schema/data/jpa/spring-jpa.xsd">

	<context:annotation-config />
	<context:component-scan base-package="" />
	<tx:annotation-driven transaction-manager="transactionManager"/>
	
	
	<bean id="transactionManager" class="org.springframework.orm.jpa.JpaTransactionManager">
		<property name="entityManagerFactory" ref="entityManagerFactory" />
	</bean>
	
	
	<!-- Configure the entity manager factory bean -->
	<bean id="entityManagerFactory"
		class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
		<property name="dataSource" ref="dataSource" />
		<property name="jpaVendorAdapter" ref="hibernateJpaVendorAdapter" />
		<!-- Set JPA properties -->
		<property name="jpaProperties">
			<props>
				<prop key="hibernate.dialect">org.hibernate.dialect.Oracle10g</prop>
			</props>
		</property>
		<!-- Set base package of your entities -->
		<property name="packagesToScan" value="com.mugil.org.model" />
	</bean>
	
	
	<beans:bean id="dbDataSource" class="org.springframework.jndi.JndiObjectFactoryBean" scope="singleton" lazy-init="true">
    	<beans:property name="jndiName" value="java:jboss/datasources/TurboDS"/>
	</beans:bean>	
</beans>

SpringMVC

Posted in JPA.

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.

Entity Manager is responsible for listener, entities, relationships, persist lifecycle of them and this interface defines the methods that are used to interact with the persistence context associated with an specific persistence context

TransactionManager is responsible for transactional data access, giving support to all the transaction that need to occurs within your application.

Transaction manager belongs with the Service layer, Entity Manager belong to the persistence layer

EntityManagerFactory and EntityManager are defined by the JPA standard. SessionFactory and Session are hibernate-specific. The EntityManager invokes the hibernate session under the hood

Why to prefer JPA API over the proprietary Hibernate?
The JPA API is cleaner than the Hibernate, Offers something that you can reuse in more other projects relying on a different implementation.

You can get the Hibernate Session from the JPA EntityManager

Session session = entityManager.unwrap(Session.class);

By using EntityManager, code is no longer tightly coupled with hibernate

JPA       - javax.persistence.EntityManager
Hibernate - org.hibernate.ejb.HibernateEntityManager