Chapter 6. Database Configuration [DRAFT (1.0-pre)]

Table of Contents

6.1. JDBC Drivers
6.1.1. Automatic JDBC Driver Installation
6.2. Database Pools as Connectors and the TranQL RAR
6.3. Easy Configuration and Deployment using the Console
6.3.1. Create a new JDBC Pool
6.3.2. Create a new XA Database Pool
6.3.3. Import a Pool from Another Application Server
6.3.4. Generate a Plan for an Application or Client Scoped Pool
6.3.5. Edit an Existing Pool
6.4. Manual Configuration and Deployment
6.4.1. Configuring a Database Pool
6.4.2. Deploying a Database Pool
6.5. Using a Database Pool
6.5.1. Updating the Module's Deployment Information
6.5.2. Application Code
6.6. Reconfiguring a Previously Deployed Pool

Most enterprise applications use a relational database in one way or another. Geronimo provides database connection pools, so you can bind a certain database into JNDI, access it from your applications, and reuse existing database connections rather than constantly closing and re-opening them. When mapped as application resources, these database connection pools can be accessed from:

Geronimo supports both standard JDBC connection pools with local transaction, and XA database pools supporting two-phase commit transactions. However, there are a limited number of supported XA drivers in Geronimo 1.0, whereas any JDBC driver should work for a normal JDBC pool.

Database connection pools may be configured at the server level, at the application level, or in the case of an application client, as a part of a single application module. The default visibility can be summarized like this:

Table 6.1. Database Connection Pool: Default Visibility

Pool TypeMultiple ApplicationsMultiple Modules in Same ApplicationClient Module Only

This chapter covers configuring database connection pools in each of these ways.


Client-scoped and application-scoped pools are started and stopped with the owning application or module, and the default reference mapping strategies ignore resources deployed in other applications. However, this is not a security feature; it's always possible to manually construct a reference to any resource running in the server (no matter what its default visibility is).

6.1. JDBC Drivers

In order to deploy any database connection to Geronimo, you need to make a JDBC driver available to it. Geronimo has a standard directory structure to accommodate additional libraries that may be required by the services, resources, or applications it runs. If you look at the repository directory under the Geronimo installation, you'll see something like this:

The JARs for the common libraries are each stored under repository/library-name/jars in Geronimo. If you wanted to add, for example, the Oracle JDBC driver, you could create the directory repository/oracle/jars and copy the Oracle JAR into that directory. A PostgreSQL JAR might likewise go under repository/postgresql/jars. Then when you configure the connection pool later, you'll list the driver JAR as a dependency.


Note that JARs in the repository should be identified using a version number in the name, so different versions of the same driver can be included in the same repository directory. Then different database pools can use separate versions of the same product's driver (for example, for Oracle 9i vs. 10g, or PostgreSQL 7.4 vs. 8.0).

6.1.1. Automatic JDBC Driver Installation

While deploying a database pool through the console, Geronimo can automatically download certain JDBC drivers and install them into the repository. This is limited to drivers that can be directly downloaded without logins, license agreements, etc. Currently that includes drivers for:

  • HSQLDB 1.7.3 and 1.8.0

  • MaxDB (SAP DB) 7.5 and 7.6

  • McKoi 1.0.3

  • MySQL (JDBC driver version 3.0 and 3.1)

  • PostgreSQL 7.3, 7.4, 8.0, and 8.1

  • SQL Server (jTDS driver version 1.1 and 1.2)

  • Sybase (jConnect 5.5 and 6.0)

Also, note that Geronimo ships with drivers for the Derby database (both JDBC and XA).