Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Vorwort
1 Neues in Java 7
2 Threads und nebenläufige Programmierung
3 Datenstrukturen und Algorithmen
4 Raum und Zeit
5 Dateien, Verzeichnisse und Dateizugriffe
6 Datenströme
7 Die eXtensible Markup Language (XML)
8 Dateiformate
9 Grafische Oberflächen mit Swing
10 Grafikprogrammierung
11 Netzwerkprogrammierung
12 Verteilte Programmierung mit RMI
13 RESTful und SOAP Web-Services
14 JavaServer Pages und Servlets
15 Applets
16 Datenbankmanagement mit JDBC
17 Technologien für die Infrastruktur
18 Reflection und Annotationen
19 Dynamische Übersetzung und Skriptsprachen
20 Logging und Monitoring
21 Java Native Interface (JNI)
22 Sicherheitskonzepte
23 Dienstprogramme für die Java-Umgebung
Stichwort
Download: - openbook, ca. 21,3 MB
Buch bestellen
Ihre Meinung?
<< zurück | Galileo Computing / <openbook> / Java 7 - Mehr als eine Insel | vor >>
Java 7 - Mehr als eine Insel von Christian Ullenboom Das Handbuch zu den Java SE-Bibliotheken
Java 7 - Mehr als eine Insel Galileo Computing 1433 S., 2012, geb. 49,90 Euro, ISBN 978-3-8362-1507-7 |
| 16 Datenbankmanagement mit JDBC
|  | 16.1 Relationale Datenbanken
|  |  | 16.1.1 Das relationale Modell
|  | 16.2 Datenbanken und Tools
|  |  | 16.2.1 HSQLDB
|  |  | 16.2.2 Weitere Datenbanken *
|  |  | 16.2.3 Eclipse-Plugins zum Durchschauen von Datenbanken
|  | 16.3 JDBC und Datenbanktreiber
|  |  | 16.3.1 Treibertypen *
|  |  | 16.3.2 JDBC-Versionen *
|  | 16.4 Eine Beispielabfrage
|  |  | 16.4.1 Schritte zur Datenbankabfrage
|  |  | 16.4.2 Ein Client für die HSQLDB-Datenbank
|  |  | 16.4.3 Datenbankbrowser und eine Beispielabfrage unter NetBeans
|  | 16.5 Mit Java an eine Datenbank andocken
|  |  | 16.5.1 Der Treiber-Manager *
|  |  | 16.5.2 Den Treiber laden
|  |  | 16.5.3 Eine Aufzählung aller Treiber *
|  |  | 16.5.4 Log-Informationen *
|  |  | 16.5.5 Verbindung zur Datenbank auf- und abbauen
|  | 16.6 Datenbankabfragen
|  |  | 16.6.1 Abfragen über das Statement-Objekt
|  |  | 16.6.2 Ergebnisse einer Abfrage in ResultSet
|  |  | 16.6.3 Java und SQL-Datentypen
|  |  | 16.6.4 Date, Time und Timestamp
|  |  | 16.6.5 Unicode in der Spalte korrekt auslesen
|  |  | 16.6.6 Eine SQL-NULL und wasNull() bei ResultSet
|  |  | 16.6.7 Wie viele Zeilen hat ein ResultSet? *
|  | 16.7 Elemente einer Datenbank hinzufügen und aktualisieren
|  |  | 16.7.1 Batch-Updates
|  |  | 16.7.2 Die Ausnahmen bei JDBC, SQLException und Unterklassen
|  | 16.8 ResultSet und RowSet *
|  |  | 16.8.1 Die Schnittstelle RowSet
|  |  | 16.8.2 Implementierungen von RowSet
|  |  | 16.8.3 Der Typ CachedRowSet
|  |  | 16.8.4 Der Typ WebRowSet
|  | 16.9 Vorbereitete Anweisungen (Prepared Statements)
|  |  | 16.9.1 PreparedStatement-Objekte vorbereiten
|  |  | 16.9.2 Werte für die Platzhalter eines PreparedStatement
|  | 16.10 Transaktionen
|  | 16.11 Metadaten *
|  |  | 16.11.1 Metadaten über die Tabelle
|  |  | 16.11.2 Informationen über die Datenbank
|  | 16.12 Vorbereitete Datenbankverbindungen
|  |  | 16.12.1 DataSource
|  |  | 16.12.2 Gepoolte Verbindungen
|  | 16.13 JPA-Beispiel mit der NetBeans-IDE
|  |  | 16.13.1 Entity-Beans generieren
|  |  | 16.13.2 Die Quellen im Überblick
|  |  | 16.13.3 Persistence Unit
|  |  | 16.13.4 Ein JPA-Beispielprogramm
|  | 16.14 Zum Weiterlesen
## 16.12 Vorbereitete Datenbankverbindungen Die Arbeit mit dem DriverManager sah bisher so aus, dass wir ihn mit der genauen Datenquelle parametrisiert haben. Wir mussten also immer den Namen der Datenbank sowie (optional) den Benutzernamen und das Passwort angeben. Diese feste Verdrahtung im Quellcode ist allerdings nicht so toll, weil Änderungen zwangsläufig zu einer neuen Übersetzung führen (was sich allerdings mit Konfigurationsdateien verändern ließe), doch die Daten stehen auf der Clientseite, wo sie nicht immer gut aufgehoben sind. Besser ist eine zentrale Stelle für die Konfigurationsdaten und auch für die Datenbank. Nehmen wir an, ein Unternehmen rüstet spontan von Oracle auf DB2 um, so müsste ein Clientprogramm an allen Stellen, an denen der Datenbanktreiber geladen und die URL für die Datenbank aufgebaut wird, im Quellcode geändert werden. Das ist unflexibel. ### 16.12.1 DataSource So gibt es in Java eine weitere Möglichkeit, nämlich die Konfigurationsdaten an einer zentralen Stelle zu hinterlegen – und das heißt in Java Zugriff über JNDI. Im zentralen Namensdienst werden Informationen über Treibername, Datenbankname und so weiter als DataSource abgelegt und dann zum nötigen Zeitpunkt erfragt. Wenn sich die Datenbank einmal ändern sollte, muss nur an dieser zentralen Stelle eine Änderung eingespielt werden, und alle, die anschließend den JNDI-Dienst erfragen, bekommen die neue Information. #### Die DataSource-Trilogie Die Verbindung zu einem Datengeber (es muss nicht unbedingt eine Datenbank sein) realisieren Objekte vom Typ DataSource-Objekt. Von der Schnittstelle DataSource gibt es drei unterschiedliche Ausführungen: ein Standard-DataSource-Objekt – mindestens das muss ein JDBC-2.0-kompatibler Treiber anbieten. ein DataSource-Objekt, das gepoolte Datenbankverbindungen zulässt (ConnectionPoolData-Source), sodass eine beendete Verbindung nicht wirklich beendet, sondern nur in einen Pool zur Wiederverwendung gelegt wird. Damit die Verbindung zurückgelegt werden kann, muss die Verbindung einfach nur geschlossen werden – ein Vorgang, der in jedem Programm mit Verbindungen zu finden sein sollte. ein DataSource-Objekt für verteilte Transaktionen (XADataSource) Das Schöne daran ist, dass der konkrete Typ verborgen bleiben kann und der Server ohne Änderung des Clients statt einer einfachen DataSource etwa eine ConnectionPoolDataSource in den Namensdienst ablegen kann. #### Verbindung über JNDI Das DataSource-Objekt ist über JNDI zu erfragen. Mit getConnection() wird anschließend das Connection-Objekt besorgt, und wir sind an der gleichen Stelle, an die uns auch der DriverManager geführt hat:
    Context ctx = new InitialContext();
    DataSource ds = (DataSource) ctx.lookup( "jdbc/database" );
    Connection con = ds.getConnection( "username", "password" );
Das javax.naming.Context-Objekt und dessen Methode lookup() erfragen das mit dem Namen assoziierte Objekt vom Verzeichnisdienst. Vorher muss natürlich irgendjemand dieses Objekt dort abgelegt – auf Neudeutsch »deployed« – haben, doch das sehen wir uns später an. Mit dem Verweis auf das DataSource-Objekt können wir getConnection() aufrufen und Benutzername und Passwort angeben.
    interface javax.sql.DataSource
    extends Wrapper, AutoCloseable
Connection getConnection(String username, String password) Versucht, unter Angabe des Benutzernamens und Passworts eine Verbindung aufzubauen. Connection getConnection() Versucht, eine Verbindung ohne Angabe von Benutzername und Passwort aufzubauen. #### Eine DataSource im JNDI-Kontext deployen * Der Administrator ist nun dafür verantwortlich, dass das DataSource-Objekt, also die Beschreibung der Datenbank-Parameter, im Namensdienst eingetragen ist. Im Allgemeinen macht das der Container über eine XML-Beschreibungsdatei oder über eine GUI, sodass kein Programmieraufwand von Hand nötig ist. Wie die JNDI-DataSource in den Web-Container Tomcat integriert werden kann, zeigt die Webseite http://tomcat.apache.org/tomcat-7.0-doc/ jndi-resources-howto.html. Zum Testen wollen wir den einfachen Namensdienst Simple-JNDI (http://code.google.com/p/osjava/wiki/SimpleJNDI) nutzen, der die Daten im Speicher hält und keinen Server startet. Aus dem Zip-Archiv von der Webseite http://code.google.com/p/osjava/downloads/detail? name=simple-jndi-0.11.4.1.zip muss dazu das Archiv simple-jndi-0.11.4.1.jar zusätzlich zum Datenbanktreiber in den Klassenpfad aufgenommen werden. In den Klassenpfad setzen wir auch die Datei jndi.properties, die Java bei Bildung eines Exemplars von InitialContext automatisch lädt: Listing 16.11: src/jndi.properties
    java.naming.factory.initial=org.osjava.sj.SimpleContextFactory
    org.osjava.sj.root=config/
In das Projektverzeichnis legen wir unter einem neuen Verzeichnis config die Datei Tutego-DS.properties. Damit kann Simple-JNDI die Datenquelle automatisch initialisieren: Listing 16.12: config/TutegoDS.properties
    type=javax.sql.DataSource
    driver=org.hsqldb.jdbcDriver
    url=jdbc:hsqldb:file:TutegoDB;shutdown=true
    user=sa
    password=
Wir könnten den Namensdienst zwar dank der Implementierung der JNDI-API auch selbst konfigurieren, aber eine passende Datei macht das automatisch. Aufgrund des Dateinamens legt Simple-JNDI automatisch für uns eine Datenquelle »TutegoDS« im Namenskontext an. Der Zugriff gestaltet sich einfach: Listing 16.13: com/tutego/insel/jdbc/JdbcWithDS.java
    package com.tutego.insel.jdbc;

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

    public class JdbcWithDS
    {
      public static void main( String[] args ) throws Exception
      {
        Connection con = null;

        try
        {
          DataSource ds = (DataSource) new InitialContext().lookup( "TutegoDS" );
          con = ds.getConnection();
          ResultSet rs =
            con.createStatement().executeQuery( "SELECT * FROM Customer" );

          while ( rs.next() )
            System.out.printf( "%s, %s %s%n", rs.getString( 1 ), rs.getString( 2 ),
                               rs.getString( 3 ) );
        }
        finally
        {
          if ( con != null )
            try { con.close(); } catch ( SQLException e ) { e.printStackTrace(); }
        }
      }
    }
An diesem Beispiel ist gut abzulesen, dass die Konfiguration nun extern ist. Der Datenbanktreiber muss nun nicht mehr von uns geladen werden, und die Verbindungsdaten sind auch nicht mehr sichtbar.
Hinweis
Eine Alternative ist, über die rmiregistry zu gehen, die ebenfalls einen kleinen JNDI-Server enthält. Der Schlüssel für java.naming.factory.initial ist dann com.sun.jndi.rmi.registry. RegistryContextFactory und die java.naming.provider.url lautet entsprechend dem Rechner mit dem Namensdienst, etwa rmi://localhost:1099. Der Server muss nur noch die DataSource aufbauen und in den Namenskontext legen.
### 16.12.2 Gepoolte Verbindungen Da der Auf- und Abbau von Datenbankverbindungen relativ teuer ist, soll eine Java-Applikation die Verbindung nur vordergründig schließen, ein spezieller pooling-fähiger Datenbanktreiber soll die Verbindung allerdings für die nächste Operation offen halten. Für gepoolte Datenbankverbindungen gibt es eine Reihe quelloffener Implementierungen; zu ihnen zählen Apache Commons DBCP (http://commons.apache.org/dbcp/) oder Proxool (http://proxool. sourceforge.net/). Simple-JNDI unterstützt DBCP direkt, sodass wir es an dieser Stelle einsetzen wollen. Die Zeile pool=true veranlasst Simple-JNDI dazu: Listing 16.14: TutegoDS.properties
    type=javax.sql.DataSource
    driver=org.hsqldb.jdbcDriver
    url=jdbc:hsqldb:file:TutegoDB;shutdown=true
    user=sa
    password=
    pool=true
Dazu sind in den Klassenpfad das Haupt-Archiv commons-dbcp-1.4.jar (Download unter http://commons.apache.org/dbcp/download_dbcp.cgi) und zusätzlich das Java-Archiv commons-pool-1.3.jar (von Jakarta Commons Pool, Download unter http://commons.apache.org/pool/download_pool.cgi) aufzunehmen. ### Ihr Kommentar Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen. >> Zum Feedback-Formular
<< zurück | <top> | vor >>
Zum Katalog
Java 7 – Mehr als eine Insel Jetzt bestellen
Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen? Ihre Meinung
Buchempfehlungen
| Java und XML
| Einstieg in Eclipse 3.7
| Android 3
| NetBeans Platform 7
| Java ist auch eine Insel
| Apps entwickeln für Android 4
| Java 7
Shopping
Versandkostenfrei bestellen in Deutschland und Österreich Info

Copyright © Galileo Press 2012
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

[Galileo Computing]
Galileo Press, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de