|
|
Wie schon in Kapitel 10.3 erläutert wurde, beinhaltet das Package java.sql insgesamt 26 Klassen. Um diesen Kern von JDBC einfach und damit übersichtlich halten zu können, wurden Standarderweiterungen für JDBC in das sog. Standard Extension API ausgelagert. Die wichtigsten dieser Standarderweiterungen sind:
Im Folgenden werden diese Erweiterungen kurz vorgestellt. Java Naming and Directory Interface Durch die explizite Angabe eines Treibers und einer URL zur Anbindung eines DBMS im Java-Code (siehe die folgenden Anweisungen) entsteht eine Abhängigkeit zwischen einem bestimmten Anbieter von Datenbanktreibern und dem Speicherort des DBMS in Form einer URL. Connection mein_con = DriverManager.getConnection(db_url, userID, passwd); Bei Änderungen des Treibers oder der URL muss dann auch jedes Mal der Programm-Code geändert werden. Eine Unabhängigkeit von Treiber und URL sollte daher stets angestrebt werden. Das Konzept des Java Naming and Directory Interface (JNDI) stellt einen einheitlichen Weg für Anwendungen zur Verfügung, um entfernte Dienste zu finden und darauf zuzugreifen. Das JNDI legt logische Namen sowohl für die zu verwendenden Datenbanken als auch für den jeweiligen Treiber fest, anstatt im Code eine spezielle Datenbank und einen bestimmten Treiber starr anzugeben. Zur Umsetzung des Konzepts erhält eine Anwendung ein DataSource-Objekt, das ein Connection-Objekt erzeugen kann. Hierbei ist jedoch unbekannt, mit welchem DBMS die Anwendung verbunden ist. In JNDI können DataSource-Objekte ausgetauscht werden, so dass eine Applikation automatisch mit anderen DBMS verbunden wird, ohne dass der Code der Applikation geändert werden muss. JNDI stellt hierzu eine neues Interface zur Verfügung: DataSource. Ein DataSource-Objekt repräsentiert ein DBMS und ist für die Erzeugung von Verbindungen (sog. Connections) zuständig. Ein DataSource-Objekt wird an einer bestimmten Stelle im JNDI-Service-Provider (SP) mit Hilfe der folgenden Syntax abgelegt:
SampleDataSource sds = new SampleDataSource("meinServer","meineDatenBank"); Context ctx = new InitialContext(); Die Anwendung kann anschließend über JNDI auf das DataSource-Objekt, das in diesem Pfad gespeichert ist, zurückgreifen:
Context ctx = new InitialContext(); Connection con = ds.getConnection(); JNDI befindet sich noch in der Entwicklung. Für weitere Informationen sei auf die Webseiten der Firma Javasoft hingewiesen. Connection Pooling Das Konzept des Verbindungszusammenschlusses (sog. Connection Pooling) wird voraussichtlich Teil des momentan in der Entwicklung befindlichen Packages javax.sql werden. Ein Verbindungszusammenschluss verwaltet physikalische Verbindungen zum DBMS in einem Cache. Wenn eine Java-Anwendung eine Verbindung zum DBMS anfordert, sucht der Connection-Pooling-Algorithmus im Cache nach einem entsprechenden PooledConnection-Objekt. Ist kein gewünschtes PooledConnection-Objekt vorhanden, so wird eine neue physikalische Verbindung, eine Instanz von der Klasse PooledConnection, zum DBMS aufgebaut. Die Java-Anwendung erhält dann ein Objekt vom Typ Connection, das von einer entsprechenden PooledConnection erzeugt wurde. Die Erzeugung eines solchen Objektes erfolgt für die Java-Anwendung transparent. Hierbei wird eine virtuelle Verbindung verwendet, deren Anfragen an ein PooledConnection-Objekt weitergegeben werden. Durch JNDI wird dann eine vom Benutzer gewünschte JDBC-Implementierung bzw. eine JDBC-Implementierung mit Connection-Pooling an eine Java-Anwendung übergeben. Distributed Transaction Support Die Unterstützung von verteilten Transaktionen erlaubt es einer JDBC-Anwendung, einen Treiber zu verwenden, der seinerseits das standardmäßig verfügbare Two-Phase-Commit-Protokoll (TPC) des Java-Transaction-APIs (JTA) verwendet. Dadurch wird der Einsatz von JDBC im Kontext von Enterprise-JavaBeans vereinfacht.
Abb. 10.11: JDBC-Unterstützung für verteilte Transaktionen Unter einer Transaktion versteht man die Bündelung mehrerer Datenbankoperationen, die in einem Mehrbenutzersystem als Einheit fehlerfrei auszuführen sind, wobei unerwünschte Einflüsse durch andere Transaktionen ausgeschlossen sind. Wird durch das DBMS keine Fehlermeldung ausgegeben, so wird eine JDBC-Transaktion mit dem Schlüsselwort commit abgeschlossen. Tritt hingegen ein Fehler auf, so wird die JDBC-Transaktion zurückgesetzt, wofür die Schlüsselwörter abort oder rollback Verwendung finden. Wie in Abb. 10-11 dargestellt ist, registrieren sich alle Verbindungen über einen Ressource-Manager beim Transaction-Manager. Hierbei werden eine Vielzahl von verschiedenen Anweisungen verschiedener DBMS vom Transaction-Manager zu einer einzigen Transaktion zusammengefasst. Durch die Verwendung dieses Konzepts wird dem Anwendungsentwickler daher das Transaktions-Management in verteilten Systemen erleichtert. |
|
|
