The scenario that the memory issue may happen:

• One EntityManagerFactory and One EntityManager are used throughout the whole session;
• The session contains a lot of queries, they are all read-only queries;
• Most queries are to retrieve database records based on primary keys;
• The records retrieved are approximately evenly distributed across primary keys;
• The database being queried has a large amount of data.

It seems that OpenJPA keeps references to data retrieved from the queries as cache. This prevents JVM garbage collecting them. Eventually, out of memory error happens.

This time, it seems that the call to clear method on EntityManager does not even work. Finally, we added the following properties and it seemed to solve the issue:

openjpa.AutoDetach=nontx-read

In fact, it is not a good practice to use EntityManager as shown in the scenario. Maybe the initial consideration is to re-use the single EntityManager as much as possible to help improve the performance of the session that is created in a batch process.

In general, the EntityManager object should not live in the whole long session. Instead it should be created on demand and closed and disregarded when finishing its unit of work. However, i haven’t got time to test how worse the performance can degrade if it is implemented this way.

Java beans in Spring can also have their collection properties populated in the beans.xml file. The collection properties here mean things like List, Map and Array.

For example, if you want to create a JPA EntityManagerFactory with a set of connection properties, these properties can be configured in beans.xml like this:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xmlns:p="http://www.springframework.org/schema/p"
  xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">
    <bean id="entityManagerFactoryCreator" 
    class="com.mytechtip.example.EntityManagerFactoryCreator">
    <property name="persistenceUnitName" value="HRMN_Repository"/>
    <property name="jpaProperties">
      <props>
        <prop key="openjpa.ConnectionURL">the_url</prop>
        <prop key="openjpa.ConnectionDriverName">the_driver_class_name</prop> 
        <prop key="openjpa.ConnectionUserName">the_user_name</prop>
        <prop key="openjpa.ConnectionPassword">the_password</prop>
      </props>
    </property>
  </bean>
</beans>

Here, jpaProperties in the actual java class “EntityManagerFactoryCreator” is an instance of Properties. And you can just use this properties to create EntityManagerFactory.

    // ...
    private Properties jpaProperties;
    //...
    public void setJpaProperties(Properties prop) {
        this.jpaProperties = prop;
    }
    // ...
    public EntityManagerFactory create() {
        return Persistence.createEntityManagerFactory("myPersistenceUnit", prop);
    }

Actually, Spring already have something similar for you to access EntityManagerFactory with ease. The beans used for the task are:

• org.springframework.orm.jpa.LocalEntityManagerFactoryBean
• org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean

More information / examples can be found here about the support of JPA entity manager factory creatation in Spring.

Some times it is necessary to load the records line by line from a large file and insert into the database table. There can be several ways to do this:

• Use the database provided tool to load the data into table. It can be a special sql command or a special stored procedure. This method is quite database specific and not portable.
• Write the program to load the data into the database table (Using JDBC if the program is written in Java).  This method can be applied to different databases if the insert SQL statement conforms to a level of standard.
• Use JPA to persist the object one by one. This allows for changing database more easily (under the condition that the JPA provider supports the database.

We used the third options to load the records into the database as we want to support multiple databases without  low level tweaking. However, the first implementation seemed very slow compared with the second option. And it became slower and slower when process of persisting records  progressed.

After a few checking, we realized that we didn’t call the method “clear” of the class EntityManager each time we persisted the object.  The EntityManager kept managing these objects so the resource was not released immediately, making it become slower and slower.

Once we add the “clear” method call, the performance became acceptable. So lesson learned about the use of JPA.