Dieser Abschnitt vermittelt einige Grundkonzepte von J2EE, die für die Arbeit mit Connector/J von Bedeutung sind.

import java.sql.Connection;
import java.sql.SQLException;
import java.sql.Statement;

import javax.naming.InitialContext;
import javax.sql.DataSource;


public class MyServletJspOrEjb {

    public void doSomething() throws Exception {
        /*
         * JNDI Initial-Kontext erstellen, um die
         *  DataSource nachschlagen zu können
         *
         * In Produktionscode sollte dieser als Objekt oder statische Variable
         * gespeichert werden, da die Erstellung eines
         * JNDI-Kontexts sehr aufwändig sein kann.
         *
         * Hinweis: Der Code funktioniert nur, wenn Sie Servlets
         * oder EJBs in einem J2EE-Anwendungsserver verwenden. Nutzen Sie
         * Verbindungspooling in Standalone-Java-Code, so
         * müssen sie die Datenquellen mit den Mitteln erstellen/konfigurieren,
         * die Ihre jeweilige Bibliothek für Verbindungspooling
         * zur Verfügung stellt.
         */

        InitialContext ctx = new InitialContext();

         /*
          * Nachschlageoperation auf der DataSource mit einem vom Anwendungsserver
          * bereitgestellten Pool im Rücken. DataSource-Objekte sollten ebenfalls
          * als Instanzvariablen zwischengespeichert werden,
          * da auch JNDI-Lookups aufwändig sind.
          */

        DataSource ds = (DataSource)ctx.lookup("java:comp/env/jdbc/MySQLDB");

        /*
         * Der folgende Code würde eigentlich in die 'service'-Methode Ihres
         * Servlets, JSPs oder EJBs gehören, dorthin, wo
         * sie mit einer JDBC-Verbindung arbeiten müssen.
         */

        Connection conn = null;
        Statement stmt = null;

        try {
            conn = ds.getConnection();

            /*
             * Die weitere Arbeit mit MySQL wird mit normaler JDBC-Programmierung
             * erledigt. Schließen sie jede Ressource, wenn Sie sie nicht mehr benötigen,
             * damit die Verbindungspool-Ressourcen so rasch wie möglich
             * wiederhergestellt werden
             */

            stmt = conn.createStatement();
            stmt.execute("SOME SQL QUERY");

            stmt.close();
            stmt = null;

            conn.close();
            conn = null;
        } finally {
            /*
             * Hier werden jdbc-Objekte abgeschlossen, die im normalen
             * Code nicht explizit geschlossen worden sind. So
             * entstehen keine Ressourcen-'Lecks'...
             */

            if (stmt != null) {
                try {
                    stmt.close();
                } catch (sqlexception sqlex) {
                    // ignorieren -- da wir hier sowieso nichts daran tun können
                }

                stmt = null;
            }

            if (conn != null) {
                try {
                    conn.close();
                } catch (sqlexception sqlex) {
                     // ignorieren -- da wir hier sowieso nichts daran tun können
                }

                conn = null;
            }
        }
    }
}

Die folgenden Hinweise beruhen auf den Anleitungen für Tomcat-5.x in http://jakarta.apache.org/tomcat/tomcat-5.0-doc/jndi-datasource-examples-howto.html Dies ist zum Zeitpunkt der Erstellung dieses Dokuments die aktuelle Version.

Zuerst installieren Sie die mit Connector/J mitgelieferte .jar-Datei in $CATALINA_HOME/common/lib, sodass sie allen in dem Container installierten Anwendungen zur Verfügung steht.

Nun konfigurieren Sie die JNDI-DataSource, indem Sie $CATALINA_HOME/conf/server.xml in dem Kontext, der Ihre Webanwendung definiert, eine Ressourcendeklaration hinzufügen:

<Context ....>

  ...

  <Resource name="jdbc/MySQLDB"
               auth="Container"
               type="javax.sql.DataSource"/>

  <!-- Muss _genau_  mit dem oben verwendeten Namen übereinstimmen!

       Der Verbindungspool wird mit dem Namen
       "java:/comp/env/jdbc/MySQLDB" in JNDI eingebunden
  -->

  <ResourceParams name="jdbc/MySQLDB">
    <parameter>
      <name>factory</name>
      <value>org.apache.commons.dbcp.BasicDataSourceFactory</value>
    </parameter>

    <!-- Stellen Sie diesen Wert nicht höher als max_connections auf Ihrem
         MySQL-Server ein. Normalerweise sollte er 10 oder einige Dutzend
         Verbindungen vorsehen, nicht hunderte oder tausende -->

    <parameter>
      <name>maxActive</name>
      <value>10</value>
    </parameter>

    <!-- Sie möchten nicht zu viele untätige Verbindungen unnötig offen lassen,
         nur ein paar, um mögliche Belastungsspitzen zu
         absorbieren -->

    <parameter>
      <name>maxIdle</name>
      <value>5</value>
    </parameter>

    <!-- Bitte verwenden Sie nicht autoReconnect=true, erstens wird es irgendwann abgeschafft
         und zweitens ist es ein Kreuz für ältere Verbindungspools, die
         keine Verbindungen testen konnten. Sie müssen entscheiden, ob Ihre Verbindung
         SQLExceptions beherrschen soll (Hinweis: das sollte sie!)  und wie viel
         Leistungseinbußen Sie hinnehmen wollen, um zu gewährleisten, dass
         die Verbindung "frisch" ist -->

    <parameter>
      <name>validationQuery</name>
      <value>SELECT 1</value>
    </parameter>

   <!-- Der konservativste Ansatz ist: Testen Sie Verbindungen, bevor
        Ihre Anwendung sie bekommt. Für die meisten Anwendungen ist das gut,
        außerdem ist die obige Anfrage ganz klein und belegt kaum Serverressourcen,
        abgesehen von der Zeit, die es braucht,
        sie im Netzwerk zu übermitteln.

        Wenn Sie eine Hochlast-Anwendung haben, werden Sie
        eine andere Lösung suchen müssen. -->

    <parameter>
      <name>testOnBorrow</name>
      <value>true</value>
    </parameter>

   <!-- Ansonsten, oder zusätzlich zu testOnBorrow, können Sie testen,
        während die Verbindung untätig ist  -->

    <parameter>
      <name>testWhileIdle</name>
      <value>true</value>
    </parameter>

    <!-- Diesen Wert müssen Sie einstellen, sonst wird
          der Idle-Evicter-Thread nie ausgeführt, selbst wenn Sie
         veranlasst haben, dass untätige Verbindungen getestet werden -->

    <parameter>
      <name>timeBetweenEvictionRunsMillis</name>
      <value>10000</value>
    </parameter>

    <!-- Verbindungen sollten nie zu lange untätig herumsitzen,
         jedenfalls nicht länger als wait_timeout in der Serverkonfiguration.
         Einige Minuten oder Minutenbruchteile sind hier
         manchmal akzeptabel, es hängt von Ihrer Anwendung
         und den Belastungsspitzen ab -->

    <parameter>
      <name>minEvictableIdleTimeMillis</name>
      <value>60000</value>
    </parameter>

    <!-- Benutzername und Passwort für die MySQL-Verbindung -->

    <parameter>
     <name>username</name>
     <value>someuser</value>
    </parameter>

    <parameter>
     <name>password</name>
     <value>somepass</value>
    </parameter>

    <!-- Klassenname für den Connector/J-Treiber -->

    <parameter>
       <name>driverClassName</name>
       <value>com.mysql.jdbc.Driver</value>
    </parameter>

    <!-- Der JDBC-Verbindungs-URL für MySQL. Wenn Sie andere
         MySQL-spezifische Parameter üübergeben möchten, müssen Sie
         dies hier im URL tun. Sie in den obigen Parameter-Tags
         einzustellen, hätte keine Wirkung. Außerdem müssen Sie
         &amp; als Trennzeichen zwischen die Parameterwerte setzen, da das
         Ampersand in XML ein reserviertes Zeichen ist. -->

    <parameter>
      <name>url</name>
      <value>jdbc:mysql://localhost:3306/test</value>
    </parameter>

  </ResourceParams>
</Context>

Generell sollten Sie die Installationsanleitung zu Ihrer Tomcat-Version befolgen, da sich die Datenquellenkonfiguration in Tomcat von Zeit zu Zeit ändert. Leider wird, wenn Sie in Ihrer XML-Datei die verkehrte Syntax verwenden, eine Ausnahme wie diese angezeigt:

Error: java.sql.SQLException: Cannot load JDBC driver class 'null ' SQL
state: null 

Die folgenden Anleitungen beziehen sich auf JBoss-4.x. Um die Klassen des JDBC-Teibers dem Anwendungsserver zur Verfügung zu stellen, kopieren Sie die .jar-Datei von Connector/J in das lib-Verzeichnis für Ihre Server-Konfiguration (normalerweise heißt es default). Dann legen Sie in demselben Konfigurationsverzeichnis in einem Unterverzeichnis namens deploy eine Datenquellenkonfigurationsdatei an, die mit "-ds.xml" endet. Diese veranlasst JBoss, die betreffende Datei als JDBC-Datasource einzusetzen. Die Datei sollte folgendes enthalten:

<datasources>
    <local-tx-datasource>
        <!-- Dieser Verbindungspool wird in JNDI unter dem Namen
             "java:/MySQLDB" eingebunden -->

        <jndi-name>MySQLDB</jndi-name>
        <connection-url>jdbc:mysql://localhost:3306/dbname</connection-url>
        <driver-class>com.mysql.jdbc.Driver</driver-class>
        <user-name>user</user-name>
        <password>pass</password>

        <min-pool-size>5</min-pool-size>

          <!--  Stellen Sie diesen Wert nicht höher als max_connections auf Ihrem
          MySQL-Server ein. Normalerweise sollte er 10 oder einige Dutzend
          Verbindungen vorsehen, nicht hunderte oder tausende -->

        <max-pool-size>20</max-pool-size>

          <!-- Verbindungen sollten nie zu lange untätig herumsitzen,
          jedenfalls nicht länger als wait_timeout in der Serverkonfiguration.
          Einige Minuten oder Minutenbruchteile sind hier
          manchmal akzeptabel, es hängt von Ihrer Anwendung
          und den Belastungsspitzen ab -->

        <idle-timeout-minutes>5</idle-timeout-minutes>

        <!-- Wenn Sie Connector/J 3.1.8 oder höher benutzen, können Sie
             unsere Implementierung verwenden, um die Stabilität
             des Verbindungspools zu erhöhen. -->

        <exception-sorter-class-name>com.mysql.jdbc.integration.jboss.ExtendedMysqlExceptionSorter</exception-sorter-class-name>
        <valid-connection-checker-class-name>com.mysql.jdbc.integration.jboss.MysqlValidConnectionChecker</valid-connection-checker-class-name>

    </local-tx-datasource>
</datasources>