Associating persistence units and data sources
Java Persistence API (JPA) applications allow us to specify the underlying data source used by the persistence provider to access the database.
The appserver provides three methods for defining the data sources in the persistence.xml file.
- Explicitly specify the JNDI name in the persistence.xml file, and the application will directly reference the data source. Switching to another data source requires an update to the persistence.xml file. JPA has two transactional patterns for accessing a data source:
- The JTA resource pattern depends on global transactions. The JTA resource pattern is typically used within the scope of an EJB session facade. This allows the session bean to control transaction and security contexts while JPA handles the persistence mappings. In this case, the application does not use the EntityTransaction interface but relies on the EntityManager enlisted with the global transaction when it is accessed.
- The non-JTA resource pattern is generally used when dealing with a single resource in the absence of global transactions. The non-JTA resource pattern is typically used within the scope of a web application or an application client. The application controls the transaction with the data source with the EntityTransaction interface.Within the appserver, the use of the <non-jta-data-source> element requires a special configuration for a non-transactional data source. Data sources that are configured for the appserver will not function as a <non-jta-data-source>, because all data sources that are configured by the appserver are automatically enlisted with the current transactional context. To prevent this automatic enlistment, add an additional data source custom property nonTransactionalDataSource=true:
- Select Resources > JDBC > Data sources
- Select the name of the data source to configure.
- Select WAS data source properties from the Additional Properties heading.
- Select Non-transactional data source.
- Click OK.
Avoid trouble: The JPA spec assumes that connections will be obtained with an isolation level that does not hold long term locks in the database, such as READ_COMMITTED. This may not match the WAS default isolation level, which is REPEATABLE_READ for most databases. We can check the level which is used for the database by referring to the topic Requirements for setting isolation level.If the default for your database is not READ_COMMITTED, you may change the default by adding an additional data source custom property webSphereDefaultIsolationLevel.
The following table shows the valid values.
Table 1. Isolation level values
Value Isolation Level 1 READ_UNCOMMITTED 2 READ_COMMITTED (JPA default) 4 REPEATABLE_READ (WAS default) 8 SERIALIZABLE If the isolation level is set to a value that will hold long-term read locks, we need to configure the JPA provider to use Pessimistic Locking instead of the default Optimistic Locking. For the JPA provider included with WAS, you may do this by adding the following properties to persistence.xml file:
<property name="openjpa.Optimistic"="false"/> <property name="openjpa.LockManager"=pessimistic"/>The JPA spec mandates that the data sources defined in the <jta-data-source> and <non-jta-data-source>elements of a persistence unit register in the JNDI name space.
For example, the persistence.xml file should contain an entry similar to the following:
<jta-data-source>jdbc/FooBarDataSourceJNDI</jta-data-source>- The JPA solution for the appserver extends the implementation to allow us to reference data sources in component name space. In the EJB or Web module deployment descriptor file, this is the <resource-ref> element. We can prefix the data source with java:comp/env/ so the application indirectly references the data source by using the local JNDI name. In this association, the application does not require updates, you change the <resource-ref> to use another data source. See the following example:
<jta-data-source>java:comp/env/jdbc/FooBarDataSourceJNDI</jta-data-source>Avoid trouble: JPA specifications do not require implementations to include data sources referenced through local JNDI names, so this method of reference may not be portable to other implementations of JPA.
- We can declare openjpa.Connection* properties in the persistence unit. If not using JPA inside the appserver, we need to use this method:Example
<property name="openjpa.ConnectionDriverName" value="org.apache.derby.jdbc.EmbeddedDriver" /> <property name="openjpa.ConnectionURL" value="jdbc:derby:target/database/jpa-test-database;create=true"/>
Next steps
For information about configuring data sources, see the topic on creating and configuring a data source.
For information about data sources and JPA, see the section on persistence in the Apache OpenJPA User's Guide.
Related tasks
Develop and packaging JPA applications for a Java EE environment
Develop and packaging JPA applications for a Java SE environment
Set a JDBC provider and data source
Task overview: Storing and retrieving persistent data with the Java Persistence API (JPA) 
Related information
http://fred.raleigh.ibm.com:7080/help/topic/com.ibm.websphere.base.doc/info/aes/ae/Requirements_for_setting_isolation_level37.html