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.

Java Archives (JAR) A JAR file encapsulates one or more Java classes, a manifest, and a descriptor. JAR files are the lowest level of archive. JAR files are used in J2EE for packaging EJBs and client-side Java Applications.

A WAR (Web Archive) is a module that gets loaded into a Web container of a Java Application Server. A Java Application Server has two containers (runtime environments) – one is a Web container and the other is a EJB container.

The Web container hosts Web applications based on JSP or the Servlets API – designed specifically for web request handling – so more of a request/response style of distributed computing. A Web container requires the Web module to be packaged as a WAR file – that is a special JAR file with a web.xml file in the WEB-INF folder.

An EJB container hosts Enterprise java beans based on the EJB API designed to provide extended business functionality such as declarative transactions, declarative method level security and multiprotocol support – so more of a RPC style of distributed computing. EJB containers require EJB modules to be packaged as JAR files – these have a ejb-jar.xml file in the META-INF folder.

Enterprise applications may consist of one or more modules that can either be Web modules (packaged as a WAR file) or EJB modules (packaged as a JAR file) or both of them. Enterprise applications are packaged as EAR files – these are special JAR files containing an application.xml file in the META-INF folder.

Basically EAR files are a superset containing WAR files and JAR files. Java Application Servers allow deployment of standalone web modules in a WAR file, though internally they create EAR files as a wrapper around WAR files. Standalone web containers such as Tomcat and Jetty do not support EAR files – these are not full fledged Application servers. Web applications in these containers are to be deployed as WAR files only.

In application servers – EAR files contain configurations such as application security role mapping, EJB reference mapping and context root url mapping of web modules.

Apart from Web modules and EJB modules EAR files can also contain connector modules packaged as RAR files and Client modules packaged as JAR files.