1 / 20

Java Data Objects (JDO) und Implementierung in FastObjects

Java Data Objects (JDO) und Implementierung in FastObjects. Inhalt. Anliegen von JDO JDO aus Anwendersicht JDO intern offene Punkte. Anliegen und Ursprung. Transparente Persistenz für Java-Objekte keine Codeänderungen für Applikationsklassen implizites Speichern und Laden

lenka
Download Presentation

Java Data Objects (JDO) und Implementierung in FastObjects

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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 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. *.class *.jdo *.class Enhancement illustriert ptj

  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 FastObjects Database Transient object JVM 2 PersistenceManagers

  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 A Nach Feldzugriff ist Objekt A nicht mehr hollow 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)

More Related