+

Search Tips   |   Advanced Search

Data access and the Spring Framework


For Spring beans to access a data source, configure those beans so that the Spring Framework delegates to, and integrates with, the WAS runtime correctly.

The Spring framework wraps Spring beans with a container-management layer that, in an enterprise application environment, delegates to the underlying enterprise application runtime.

The following sections describe what to consider when you configure Spring beans that access a data source.

 

Access to data sources configured in the appserver

For a Spring application to access a resource such as a JDBC data source, the application must use a resource provider that is managed by the appserver. To do this, use the following steps.

  1. During development, configure the WAR module with a resource reference. For example:

    <resource-ref>
            <res-ref-name>jdbc/springdb</res-ref-name>
            <res-type>javax.sql.DataSource</res-type>
            <res-auth>Container</res-auth>
            <res-sharing-scope>Shareable</res-sharing-scope>
    </resource-ref>
    
    

  2. For EJB JAR files, declare the same resource reference in each EJB that needs to access the data source.

  3. Use one of the following steps:

    • Declare a data source proxy bean. In the Spring application configuration, declare a proxy bean that references a resource provider that the application server manages. Set the value of the jndiName property to java:comp/env/ followed by the value of res-ref-name property that you declared in the resource reference. For example:

      <bean id="wasDataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
        <property name="jndiName" value="java:comp/env/jdbc/springdb"/>
        <property name="lookupOnStartup" value="false"/>
        <property name="cache" value="true"/>
        <property name="proxyInterface" value="javax.sql.DataSource"/>
      </bean>
      
      

    • Alternatively, for Spring Framework V2.5 or later, use the <j2ee:jndi-lookup/> approach. Set the value of the jndi-name property to the value of the res-ref-name property that you declared in the resource reference, and the value of the resource-ref property to true. For example:

      <jee:jndi-lookup id=" wasDataSource "
                   jndi-name="jdbc/springdb"
                   cache="true"
                   resource-ref="true"
                   lookup-on-startup="false"
                   proxy-interface="javax.sql.DataSource"/>
      
      

    The Spring application can then use the data source proxy bean as appropriate.

  4. When the application is deployed to an appserver, configure a resource provider and resource data source that the Spring application resource reference can use. The resource reference that is declared in the deployment descriptor of the module will be bound to the configured data source of the appserver during deployment.

 

JDBC native connections

WAS does not support the use of the NativeJdbcExtractor class that the Spring Framework provides, so avoid scenarios that use this class. Implementations of this class access native JDBC connections and bypass quality of service functions in the appserver such as tracking and reassociating connection handles, sharing connections, managing connection pools and involvement in transactions.

As an alternative, we can use the appserver WSCallHelper class to access non-standard vendor extensions for data sources.

 

Java Persistence API

WAS V 7 and later, and WAS V6.1 Feature Pack for EJB 3.0 support the EJBs 3.0 specification, and therefore the Java Persistence API (JPA).

WAS V6.1 and later supports the use of the Apache OpenJPA implementation of JPA.

See the related links.

To use the Spring Framework with a JPA implementation, it is advisable to use JPA directly rather than using the JPA helper classes that are provided with the Spring Framework in the org.springframework.orm.jpa package.

WAS V 6.1 and later supports JPA application-managed entity managers, which might have a transaction type of either JTA or resource-local. Entity managers that have a transaction type of JTA use the JTA transaction support of the application server. We can define transaction demarcation for such entity managers using Java EE techniques or the declarative transaction model in the Spring Framework. For further information about transaction support with Spring Framework V 2.5, see the related links.

A data access object that uses JPA is packaged with a persistence.xml file that defines persistence context for the JPA EntityManager object that the application uses.

The following example shows how to set up a persistence.xml file for a JTA entity manager that uses a data source with the JNDI name java:comp/env/jdbc/springdb:

<persistence 
  
    xmlns="http://java.sun.com/xml/ns/persistence"
  
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  
    xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
  http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd" version="1.0">
  <persistence-unit name="default" transaction-type="JTA">
    <provider> org.apache.openjpa.persistence.PersistenceProviderImpl 
    </provider>
    <jta-data-source> java:comp/env/jdbc/springdb </jta-data-source>
    <properties>
      <property name="openjpa.TransactionMode" value="managed" />
      <property name="openjpa.ConnectionFactoryMode"value="managed" />
      <property name="openjpa.jdbc.DBDictionary" value="db2" />
    </properties>
  </persistence-unit>
</persistence>

The openjpa.TransactionMode and openjpa.ConnectionFactoryMode properties are set to the value managed so that the JPA EntityManager object delegates management of transactions and connections to the application server. The data access object can use the declarative transaction model in the Spring Framework for transaction demarcation. For further information about transaction support with Spring Framework V2.5, see the related links. If we wish to use annotation-style injection of a JPA EntityManager object, we need Java Platform, Standard Edition 5 (Java SE 5) or later. Therefore, we can use this method with WAS V 6.1 or later. The annotation is identical to standard JPA. For example:

@PersistenceContext private EntityManager em;

Use the following lines of XML to turn on EntityManager injection in the Spring XML configuration:

<!-- bean post-processor for JPA annotations -->
  <bean class=
  "org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor"/>

Spring will create an EntityManager object from any EntityManagerFactory instance that is defined in the Spring XML configuration file. If there is more than one EntityManagerFactory instance, creation will fail. To create an EntityManagerFactory instance, use only one of the following methods:

When the appserver supports EJB 3.0, we can create an EntityManagerFactory object using JPA through the EJB 3.0 support. This approach has the advantage that we can separate the Spring and JPA configuration. WAS V6.1 Feature Pack for EJB 3.0 and WAS V 7 and later support EJB 3.0.

Do not use this approach for versions of the appserver that do not support EJB 3.0, because any EntityManager objects that are created might not be managed correctly.

The following example code shows how to create an EntityManagerFactory object using EJB 3.0:

<bean id="myEmf" 
  class="javax.persistence.Persistence" 
  factory-method="createEntityManagerFactory" >
  <constructor-arg type="java.lang.String" value="default"/>  
</bean>





 

Related concepts


Additional Application Programming Interfaces (APIs)
Spring Framework

 

Related tasks


Develop applications that use JNDI
Assembling data access applications
Develop and packaging JPA applications for a Java EE environment

 

Related


Data access portability features

 

Related information


Leveraging OpenJPA with WAS V6.1
Spring Documentation