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 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

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

*.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

hollowA

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)