Java Data Objects (JDO) und Implementierung in FastObjects

2 Inhalt Anliegen von JDO JDO aus Anwendersicht JDO intern offene Punkte

3 Anliegen und Ursprung Transparente Persistenz für Java-Objekte keine Codeänderungen für Applikationsklassen implizites Speichern und Laden implizite Concurrency Control Spezifikation für Java, nicht andere Sprachen keine OODB-Spezifikation, auch auf RDBMS realisierbar Java-Binding Spezifikation der ODMG als Arbeitsgrundlage

4 Ursprung Geschaffen unter dem Java Community Process von Sun Leiter der Spezifikation: Craig RussellSun Microsystems, Inc. Expertengruppe, Mitglieder von: IBMInformix SoftwareEricsson Inc. OracleRational SoftwareSAP AG Software AGSun MicrosystemsPOET (und vielen anderen) akzeptiert als Standard Ende März 2002

5 JDO vs. JDBC JDBC Mapping des OO-Modells auf ein relationales Modell Code notwendig für: Transformation eines Objektes in Tupel (bzw. Menge von Tupeln) und Speichern mit SQL-Anweisungen SQL-Anweisungen zum Laden von Tupeln und deren Transformation in ein Java-Objekt explizites Laden und Speichern der Objekte Zuordnung bereits geladener Objekte zu DB-Objekten, d.h. man muß selbst Caching implementieren JDO alles automatisch und transparent ersetzt nicht JDBC, kann mit diesem realisiert werden

6 JDO aus Anwendersicht - Applikationsklassen Anwender legt fest, welche Klassen persistenzfähig sind d.h. Objekte dieser Klassen können gespeichert werden Applikationsklassen werden wie gewohnt entworfen, Unterstützung für alle wesentlichen Elementtypen primitive Typen, Referenzen auf andere persistente Objekte, viele Collection-Klassen usw. Metainformationen (u.a. welche Klassen sind persistenzfähig) wird in speziellen XML-Dateien beschrieben zur Laufzeit und während Entwicklung benötigt Restriktionen an Benennung und Plazierung dieser Dateien

7 Enhancen Persistenzfähige Klassen müssen javax.jdo.PersistenceCapable implementieren nicht beliebig, sondern kompatibel zur Referenzimplementation Forderung nach Transparenz: diese Implementierung sollte automatisch erzeugt werden oftmals mit einem Post-Prozessor, der direkt ByteCode in die.class-Dateien einfügt und/oder abändert FastObjects Enhancer heißt ptj

8 Enhancer (2) Methoden zum Laden und Speichern dieser Objekte werden eingefügt werden intern von der JDO Implementation aufgerufen für alle zu speichernden Felder werden spezielle Zugriffs- Methoden (Getter und Setter) eingeführt protokollieren den internen Zustand eines Objektes (clean, dirty, …) jeder direkte Zugriff auf solche Felder wird durch Methodenaufruf ersetzt => auch nicht-persistente Klassen, die direkte Feldzugriffe bei persistenten Instanzen machen, müssen enhanced werden

9 Enhancement illustriert ptj *.jdo *.class

10 JDO aus Anwendersicht - Datenbanklogik Spezifikation definiert eine Menge von Interfaces PersistenceManager, Transaction, Extent, Query, … Implementationen dieser Interfaces durch JDO Implementierer (z.B. Poet) Anwender benutzt nur die Interfaces! Zentrales Interface:javax.jdo.PersistenceManager Persistente Java Objekte erhalten eine eindeutige ObjektId

11 javax.jdo.PersistenceManager Jeder Thread benutzt normalerweise seine eigene PersistenceManager-Instanz Jedes persistente Java-Objekt im Speicher gehört zu genau einem PersistenceManager Jedes persistente Java-Objekt korrespondiert zu genau einem Datenbank-Objekt, zwei persistente Java-Objekte des selben PersistenceManagers aber immer zu verschiedenen!

12 javax.jdo.PersistenceManager (2) JVM 1 JVM 2 FastObjects Database PersistenceManagers Transient object

13 Persistenz Objekte, die mit new angelegt wurden, sind transient Objekte, die aus der Datenbank geholt wurden, sind persistent geholt mittels Query, Iterieren über Extent, Referenz von einem anderen persistenten Objekt PersistenceManager.makePersistent() transientes Objekt wird persistent Persistenz durch Erreichbarkeit PersistenceManager.deletePersistent() löscht Objekt aus der Datenbank

14 Transaktionen Pro PersistenceManager maximal eine Transaktion offen geschachtelte Transaktionen optional, von FastObjects unterstützt Nacheinander i.d.R. mehrere Transaktionen pro PersistenceManager Objektreferenzen aus alten Transaktionen bleiben gültig PersistenceManager.currentTransaction(); Interface javax.jdo.Transaction Transaction.begin() Transaction.commit() Transaction.rollback() Transaktionen erfüllen ACID-Eigenschaften

15 Beispiel: Speichern eines Objektes import javax.jdo.*; import com.poet.jdo.*; public class Main { public static void main(String[] args) { try{ PersistenceManagerFactory pmf= PersistenceManagerFactories.getFactory(); pmf.setConnectionURL("FastObjects://LOCAL/myBase"); PersistenceManager pm=pmf.getPersistenceManager(); pm.currentTransaction().begin(); pm.makePersistent(new Person("Donald Duck")); pm.currentTransaction().commit(); pm.close(); }catch(JDOUserException e){e.printStackTrace();} }

16 Extents Enthalten alle Objekte einer Klasse (d.h. auch Objekte von Unterklassen) Werden automatisch vom DBMS gepflegt Extent PersistenceManager.getExtent(Class, boolean) Iterator Extent.iterator()

17 JDOQL Anfragesprache, orientiert an Java-Syntax und Semantik Filterausdruck ähnelt boolschem Java-Ausdruck einige Methodenaufrufe erlaubt (String.startsWith(), …) wird gegen jedes Objekt aus der Kandidatenmenge (meist ein Extent) geprüft nicht so mächtig wie ODMG OQL Deklarationen von Imports, Variablen und Parametern analog Java-Syntax Parameter werden bei Ausführung auf Werte gesetzt Variablen sind mit Existenzquantor und zusätzlich an eine Grundmenge gebunden

18 JDO intern - Zustände von Objekten Jedes Objekt im Speicher hat einen Zustand transient, persistent-clean, persistent-dirty, hollow, … Zustandsübergänge entweder explizit (makePersistent()) oder implizit (Lese-/Schreibe-Zugriff) exakte Definition in der JDO Spezifikation Hollow-Objekte sind praktisch hohl, ermöglichen das Laden von Objekten aus der DB erst bei Bedarf

19 Hollow Objekte illustriert Objekt A ist hollow Nach Feldzugriff ist Objekt A nicht mehr hollow A A

20 Offene Punkte BLOB/CLOB Unterstützung, geschachtelte Transaktionen mit FastObjects schon jetzt möglich verschiedene Erweiterungen zu JDOQL Managed Relationships Prefetch API bei FastObjects jetzt schon AccessPatterns verwendbar Trigger bei FastObjects jetzt schon Watch & Notify Enhancer Invocation API Locking & Isolation Level Nonstatic inner classes Graph Traversal (Netwalker)