Table of Contents
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 Type||Multiple Applications||Multiple Modules in Same Application||Client 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).
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).
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
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).