Kein Folientitel - Java Forum Stuttgart
Werbung
Java Data Objects (JDO)
und
Implementierung in FastObjects
Inhalt
• Anliegen von JDO
• JDO aus Anwendersicht
• JDO intern
• offene Punkte
2
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
3
Ursprung
• Geschaffen unter dem Java Community Process von Sun
• Leiter der Spezifikation:
• Craig Russell
Sun Microsystems, Inc.
• Expertengruppe, Mitglieder von:
IBM
Informix Software
Ericsson Inc.
Oracle
Rational Software
SAP AG
Software AG
Sun Microsystems
POET
(und vielen anderen)
• akzeptiert als Standard Ende März 2002
4
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
5
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
6
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
7
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 ZugriffsMethoden (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
8
Enhancement illustriert
*.class
ptj
*.jdo
*.class
9
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
10
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!
11
javax.jdo.PersistenceManager (2)
JVM 1
FastObjects Database
Transient object
JVM 2
PersistenceManagers
12
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
13
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
14
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();}
}
}
15
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()
16
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
17
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
18
Hollow Objekte illustriert
A
Objekt A ist hollow
Nach Feldzugriff ist
A
Objekt A nicht mehr
hollow
19
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)
20
