On Java Development

Introduction

This post describes the contents of the file “jpaDataSourceContext” found in baseproject. This file contains datasource and JNDI definitions using Spring’s JPA support for Entity Manager Factory, Transaction Manager and Hibernate Adapters. The file is read during the initial phase of the application’s startup processing which occurs when the server is started. This means all data source/JNDI references, used or not, must be present and valid.

Overarching Concerns and Design Approach

Consideration has been given to Genelco’s multiple environments and library lists that control access to production and test databases which are accessible on a single iSeries. The machine uses DB2, DB2/400, UDB/400 (universal database) which are the names IBM marketing has given the DB over the years. They are one and the same.

The approach taken for database connection configuration pursues the desire to develop web applications while using only test libraries and to use the same test libraries once deployed to the server that has been assigned to the role of UAT. When deployed to the production server, the libraries must be those for production. The differences mean different connection mechanisms are used. The proper mechanism is determined based upon where the application is running, server wise.

For example, when the application is being developed on a local PC, it is running within Eclipse that relies upon a local Tomcat server. The mechanism used to acquire a connection to UDB/400 uses Spring’s JPA Entity Manager Factory Bean for Hibernate. The definitions are contained in a Spring context definition file. The JPA Entity Manager Factory Bean for Hibernate ultimately points to a data source, defined in the same context definition file with the appropriate libraries assigned to its JDBC URL definition.

When the application is deployed to the test or production server, the mechanism is different, relying more upon a JNDI definition on the server to acquire a connection with the right set of libraries. (This is somewhat complicated when multiple Genelco environments are brought into the mix.)

Since Spring resolves all datasource and JNDI configurations during startup, the JNDI definitions must also be defined for the Tomcat server on localhost, even though they will not be used during development. Instead, the datasource definitions are used during development. This allows the developer to change the datasource definitions as required for any new libraries. Prior to deployment to the TEST/PROD servers, the JNDI definitions there would be updated to reflect changes to the datasource. It should be mentioned that regardless of where the application is running, stored procedures and programs called using SETLIBLEXEC use the datasource defined in the Spring configuration.

The service-level architecture employed by baseproject is responsible for acquiring the database connection. This allows the service to use multiple DAOs within a single transaction allowing for commit and rollback across all I/O conducted by the DAOs. The illustrations that follow show the principle parts and mechanism involved in acquiring a JPA Entity Manager for a given Genelco environment.

Requesting a JPA Entity Manager During Development (localhost)

This diagram attempts to show how connections are obtained while the application is running during the time it is being developed on the local desktop PC using Eclipse an a local Tomcat server.

For localhost, the following Data Source definitions are referenced. Each definition has the appropriate library assigned to it for its related Genelco environment name.

• localhostCULDB400DataSource
• localhostFLIDB400DataSource
• localhostMHTDB400DataSource
• localhostSVLDB400DataSource

Requesting a JPA Entity Manager When Running on TEST Servers

This diagram attempts to show how connections are obtained while the application is running on the Tomcat server with the designated role of TEST.

For TEST, the following JNDI definitions are referenced. Each definition has the appropriate library assigned to it for its related Genelco environment name.

• jdbc/S1039255CUL
• jdbc/S1039255FLI
• jdbc/S1039255MHT
• jdbc/S1039255SVL

Requesting a JPA Entity Manager When Running on PROD Servers

This diagram attempts to show how connections are obtained while the application is running on the Tomcat server with the designated role of PROD.

For PROD, the following JNDI definitions are referenced. Each definition has the appropriate library assigned to it for its related Genelco environment name.

• jdbc/S1039255CUL
• jdbc/S1039255FLI
• jdbc/S1039255MHT
• jdbc/S1039255SVL

Note that these names are the same for those assigned to TEST. This is because the TEST and PROD servers each contain their own JNDI definitions within their associated context.xml file. The differences are the libraries assigned to them. The TEST server is assigned with the test libraries while the PROD server is assigned with the production libraries.

Design Benefits

The following benefits are realized when using this approach for connection management.

• Since new libraries are added to the JNDI definition on the developer’s Tomcat installation used by Eclipse, the configuration changes provides the blueprint for the changes to be made on TEST and PROD servers. In this way they can be tested before deploying to TEST and PROD.
• User ids and passwords are established at a single point, which is the JNDI definition. Changes made there affect all applications.
• Applications do not require code changes when moved from developer’s machine to TEST (i.e. UAT) and then to PROD.
• Provides a flexible approach to library management as described by this post.