OpenJPA deployment includes choosing a factory deployment strategy, and in a managed environment, optionally integrating with your application server's managed and XA transactions. This chapter examines each aspect of deployment in turn.

OpenJPA offers two EntityManagerFactory deployment options.

deployment standalone Persistence The JPA Overview describes the javax.persistence.Persistence class. You can use Persistence to obtain EntityManagerFactory instances, as demonstrated in . OpenJPA also extends Persistence to add additional EntityManagerFactory creation methods. The org.apache.openjpa.persistence.OpenJPAPersistence class Javadoc details these extensions. After obtaining the factory, you can cache it for all EntityManager creation duties. OpenJPA factories support being bound to JNDI as well.

Java EE 5 application servers allow you to inject entity managers into your session beans using the PersistenceContext annotation. See your application server documentation for details.

transactions managed TransactionManager integration managed transactions transactions TransactionMode OpenJPA EntityManagers have the ability to automatically synchronize their transactions with an external transaction manager. Whether or not EntityManagers from a given EntityManagerFactory exhibit this behavior by default depends on the transaction type you set for the factory's persistence unit in your persistence.xml file. OpenJPA uses the given transaction type internally to set the openjpa.TransactionMode configuration property. This property accepts the following modes: local: Perform transaction operations locally. managed: Integrate with the application server's managed global transactions. You can override the global transaction mode setting when you obtain an EntityManager using the EntityManagerFactory's createEntityManager(Map props) method. Simply set the openjpa.TransactionMode key of the given Map to the desired value. You can also override the openjpa.ConnectionUserName, openjpa.ConnectionPassword, and openjpa.ConnectionRetainMode settings using the given Map. ManagedRuntime In order to use global transactions, OpenJPA must be able to access the application server's javax.transaction.TransactionManager. OpenJPA can automatically discover the transaction manager for most major application servers. Occasionally, however, you might have to point OpenJPA to the transaction manager for an unrecognized or non-standard application server setup. This is accomplished through the openjpa.ManagedRuntime configuration property. This property describes an org.apache.openjpa.ee.ManagedRuntime implementation to use for transaction manager discovery. You can specify your own implementation, or use one of the built-ins: auto: This is the default. It is an alias for the org.apache.openjpa.ee.AutomaticManagedRuntime class. This managed runtime is able to automatically integrate with several common application servers. invocation: An alias for the org.apache.openjpa.ee.InvocationManagedRuntime class. You can configure this runtime to invoke any static method in order to obtain the appserver's transaction manager. jndi: An alias for the org.apache.openjpa.ee.JNDIManagedRuntime class. You can configure this runtime to look up the transaction manager at any JNDI location. See the Javadoc for of each class for details on the bean properties you can pass to these plugins in your configuration string. ]]>

transactions XA XA transactions transactions The X/Open Distributed Transaction Processing (X/Open DTP) model, designed by Open Group (a vendor consortium), defines a standard communication architecture that provides the following: Concurrent execution of applications on shared resources. Coordination of transactions across applications. Components, interfaces, and protocols that define the architecture and provide portability of applications. Atomicity of transaction systems. Single-thread control and sequential function-calling. The X/Open DTP XA standard defines the application programming interfaces that a resource manager uses to communicate with a transaction manager. The XA interfaces enable resource managers to join transactions, to perform two-phase commit, and to recover in-doubt transactions following a failure.

OpenJPA supports XA-compliant transactions when used in a properly configured managed environment. The following components are required: A managed environment that provides an XA compliant transaction manager. Examples of this are application servers such as WebLogic or JBoss. Instances of a javax.sql.XADataSource for each of the DataSources that OpenJPA will use. Given these components, setting up OpenJPA to participate in distributed transactions is a simple two-step process: Integrate OpenJPA with your application server's transaction manager, as detailed in above. Point OpenJPA at an enlisted XADataSource, and configure a second non-enlisted data source. See .