Java Datenbankpersistenz mit OJB

Transkript

1 Mittwoch, 9. November h00, Variohalle 5 J2 EE Java Datenbankpersistenz mit OJB Daniel Blonski SHE Informationstechnologie AG, Ludwigshafen Schlüsselworte: OJB, Java, OR-Mapping Einleitung Zwischen der objektorientierten Welt der Java-Entwicklung und der Struktur relationaler Datenbanksysteme herscht eine Lücke, die verschiedene objektrelationale Mapping-Werkzeuge sich anschicken zu überbrücken. Eines davon, nämlich OJB ist Gegenstand dieses Vortrages. OJB ist ein Open-Source-Werkzeug der Apache Foundation. Außer der technologischen Barriere gibt es auch eine nicht zu unterschätzende kulturelle Barriere zwischen Java-Entwicklern und Datenbankspezialisten. Auch hierfür kann ein der Java-Kultur angepasstes Werkzeug positive Auswirkungen haben. Mapping zwischen Tabellen und Klassen Grundlagen Die Abbildung zwischen Datenbanktabellen und Java-Klassen wird durch eine zentrale XML-Datei beschrieben. Wie das geht sieht man am besten an einem einfachen Beispiel. Wir möchten die Tabelle create table coctail ( coctailid number(10), name varchar2(50), preis number(5,2), alkoholisch number(1), beschreibung clob, bild blob, primary key (coctailid) ); create sequence sq_coctail; auf die Klasse class Coctail { private int coctailid; private String name; private BigDecimal preis; private boolean alkoholisch; private String beschreibung; private byte[] bild; //... Methoden }

2 18. Deutsche ORACLE-Anwenderkonferenz abbilden. In der Mapping-Datei, die standardmäßig repository_user.xml heißt, sieht das dann so aus: <class-descriptor class="ojbtest.coctail" table="coctail" > name="coctailid" column="coctailid" primarykey="true" autoincrement="true" sequence-name= sq_coctail /> name="name" column="name" /> name="preis" column="preis" /> name= akoholisch column="alkoholisch" /> name= beschreibung column= beschreibung jdbc-type="clob"/> name= bild column= bild jdbc-type= BLOB /> </class-descriptor> Forms / J2 EE Application Server Das Beispiel sollte einigermaßen selbsterklärend sein, demonstriert wird auch gleich die Verwendung von Oracle-Sequences. (Damit das funktioniert muss man zusätzlich noch an anderer Stelle den verwendeten Sequence-Manager auf SequenceManagerNextValImpl setzen.) Die LOB-Felder werden von OJB automatisch mitgeladen, so dass dieses Feature wohl eher für kleinere LOBs geeignet ist. Abbildung einer Fremdschlüsselbeziehung Als nächstes soll die Tabelle coctail zusätzlich einen Fremdschlüssel auf die Tabelle coctailgruppe enthalten. Im Java-Programm sollte dann eine Referenz auf ein Objekt der Klasse CoctailGruppe zur Verfügung stehen. (Die Definition dieser Klasse ist hier nicht wiedergegeben.) Dafür erweitern wir die Definition der Klasse um zwei Attribute: private int coctailgruppeid; private CoctailGruppe coctailgruppe; In der Mapping-Datei wird die Fremdschlüsselbeziehung folgendermaßen angegeben: name="coctailgruppeid" column="coctailgruppeid" auto-retrieve= true auto-update= link /> <reference-descriptor name="coctailgruppe" class-ref="ojbtest.coctailgruppe" > <foreignkey field-ref="coctailgruppeid"/> </reference-descriptor> auto-retrieve bedeutet, dass der referenzierte Datensatz automatisch aus der Datenbank geladen wird. Über auto-update kann gesteuert werden, ob der referenzierte Datensatz auch automatisch mit gespeichert werden soll. In unserem Fall ist das nicht erwünscht, die Einstellung link bewirkt jedoch, dass das Attribut coctailgruppeid beim speichern automatisch anhand der Referenz coctailgruppe aktualisiert wird, d.h. wenn man einen Coctail einer anderen Gruppe zuordnen will, muss man die Referenz setzen und nicht die ID.

3 Zu erwähnen wäre auch noch, dass OJB bei Fremdschlüsselfeldern die mit dem primitiven Datentyp int deklariert sind, den Wert 0 automatisch als Datenbank-NULL-Wert speichert. Das automatische Laden der Referenzen ist zwar ungemein praktisch, kann aber natürlich insbesondere bei umfangreichen Abfragen dazu führen, dass viele überflüssige Ladeoperationen ausgeführt werden. (Zur Beruhigung sei aber erwähnt, dass die Referenzen nicht über einzelne Abfragen geladen werden.) Eine Lösung ist es, auto-retrieve= false zu setzen und bei der Verarbeitung einzelner Datensätze über den Aufruf retrieveallreferences() alle Referenzen zu laden. (In Verbindung mit dem auto-update-feature ist jedoch zu beachten, dass retrieveallreferences() auf alle Fälle aufgerufen werden muss, wenn der Datensatz gespeichert werden soll, sonst denkt OJB, die Referenzen wären nicht mehr vorhanden und löscht die Daten aus der Datenbank!) Außerdem gibt es noch die gleichermaßen praktische wie ökonomische Möglichkeit, referenzierte Objekte automatisch on Demand nachzuladen. Dafür wird statt des eigentlichen Objektes nur ein Proxy- Objekt angelegt, das lediglich den Fremdschlüssel enthält. Sobald das Programm versucht auf das Objekt zuzugreifen, wird das eigentliche Objekt aus der Datenbank geladen. Dafür ist es nicht erforderlich mühsam für jede Klasse eine eigene Proxy-Klasse zu definieren, die sämtliche Methoden an die eigentliche Klasse delegiert, OJB realisiert dies mit Hilfe des dynamic-proxy Konzeptes, dass mit dem 1.3er JDK eingeführt wurde. Abbildung einer Master-Detail-Beziehung Als nächstes sollen zu einem Coctail eine Liste mit Zutaten gespeichert werden, diese sollen innerhalb der Coctail-Klasse über eine Collection zugreifbar sein. Dafür erweitern wir die Klasse folgendermaßen: private ArrayList coctailzutaten; Die Tabelle coctail_zutat hat folgenden Aufbau: create table coctail_zutat ( coctailid number(10) references coctail, zutatnr number(2), zutat_text varchar2(100), primary key(coctailid, zutatnr) ); Das Mapping der inversen Fremschlüsselbeziehung innerhalb des Mappings der Coctail-Klasse sieht in der Mapping-Datei folgendermaßen aus: <collection-descriptor name="coctailzutaten" element-class-ref="ojbtest.coctailzutat" auto-retrieve="true" auto-update="object" auto-delete="object" orderby="zutatnr" > <inverse-foreignkey field-ref="coctailid"/> </collection-descriptor> In diesem Fall sollen die Zutaten als untergeordnete Objekte des Coctails angesehen werden und automatisch mit gespeichert und gelöscht werden. Der Parameter orderby sorgt dafür, dass die Zutaten sortiert nach der zutatnr in der Collection erscheinen. Mapping von Klassenhierarchien Für die Abbildung von Klassenhierarchien gibt es drei mögliche Ansätze: Alle Klassen werden auf eine Tabelle abgebildet. Jede Klasse wird auf eine eigene Tabelle abgebildet. Die Attribute der Basisklasse werden für alle abgeleiteten Klassen in einer Tabelle gespeichert. Die zusätzlichen Attribute der abgeleiteten Klasse werden in einer eigenen Tabelle gespeichert und die Daten werden ggf. über einen Join geladen. Alle drei Ansätze werden von OJB unterstützt, die Details würden aber den Rahmen dieses Vortrags sprengen.

4 18. Deutsche ORACLE-Anwenderkonferenz Automatische Generierung des Mappings per Forward- oder Reverse-Engineering Bei einem umfangreichen Datenmodell kann es recht mühsam werden das Datenmodell, das Klassenmodell und die Mapping Datei parallel zu pflegen. OJB bietet hierfür ein XDoclet-Modul an mit dessen Hilfe automatisch die Mapping-Datei generiert wird. Falls gewünscht, können mit Hilfe von Torque auch die Datenbanktabellen automatisch angelegt werden. Das XDoclet-Modul bezieht seine Informationen aus speziellen Javadoc-Kommentaren, die z.b. so aussehen: /** table="coctail */ public class Coctail { /** column="name" * length="100" */ private String name; // Forms / J2 EE Application Server In der Praxis wird man wohl häufig eher das umgekehrte Problem haben, nämlich für ein vorhandenes Datenmodell eine Java-Anwendung zu schreiben. Auch hierfür gibt es ein Werkzeug, das aber wohl nicht mehr so ganz auf dem neuesten Stand ist. Verfügbare APIs Übersicht Für die Programmierung der Datenbankzugriffe bietet OJB gleich drei verschiedene APIs an. PersistenceBroker-API: Dies ist die native API von OJB, die auch die Grundlage für die anderen APIs bildet. ODMG-API: Dies ist eine standardisierte API, der Standard ist aber wohl mittlerweile etwas überholt und wird perspektivisch durch JDO abgelöst. JDO-API: Dies ist die neue Standard-API, die Implementierung befindet sich aber noch im Beta-Stadium. Wir haben uns aus folgenden Gründen für die PersistenceBroker-API entschieden: Gegen die Die ODMG-API sprach, dass diese auch von den Erfindern selbst als veraltet deklariert wurde und es wenig frei verfügbare Dokumentation gibt. Gegen die JDO-API sprach, dass diese von den Autoren noch nicht zum produktiven Einsatz empfohlen wird. Ein weiterer Gesichtspunkt ist, dass wir uns für die Abfragesprache OQL bzw. JDOQL nicht so richtig erwärmen konnten. Bei der PersistenceBroker-API werden Abfragen über Methodenaufrufe zusammengebaut, was für meinen Geschmack die bessere Lösung ist. Auch wenn die PersistenceBroker-API gelegentlich auch als Low-Level-API bezeichnet wird, so ist dies nicht ganz richtig. Es handelt sich durchaus um eine komfortable und intuitiv benutzbare API. Ich werde mich im folgenden auf die PersistenceBroker-API beschränken, weil der Leser über JDO auch an anderer Stelle genügend Informationen findet.

5 PersistenceBroker API Zentraler Einstiegspunkt ist die Klasse PersistenceBroker, die man sich als Kapselung einer Datenbank- Connection vorstellen kann. Hier ein kleines Beispiel zum Speichern eines neuen Objektes: Coctail coctail = new Coctail(); coctail.setname("piña Colada"); //... PersistenceBroker broker = null; try { broker = PersistenceBrokerFactory.defaultPersistenceBroker(); broker.begintransaction(); broker.store(coctail); broker.committransaction(); }catch(persistencebrokerexception e) { if(broker!= null) broker.aborttransaction(); throw new Exception("..."); } finally { if (broker!= null) broker.close(); } Nach dem Speichern des Objektes ist dann auch die neu generierte coctailid gesetzt. Der Aufruf broker.store(objekt) wird auch zum Speichern von vorhandenen Datensätzen verwendet. Kommen wir jetzt zu einem Beispiel für eine Abfrage: Criteria criteria = new Criteria(); criteria.addlessorequalthan("preis", new BigDecimal("3.5"); criteria.addequalto("alkoholisch", new Boolean(true)); QueryByCriteria query = new QueryByCriteria( Coctail.class, criteria); Collection results = broker.getcollectionbyquery(query); Es stehen auch noch zahlreiche andere Ausdrücke zum Zusammenbauen von Abfragen zur Verfügung, hier ist eine Auswahl: Aufbau einer where coctailid in (...)-Abfrage: Collection idliste = new ArrayList(); idlist.add(new Integer(3)); idlist.add(new Integer(5)); criteria.addin("coctailid, idliste); Verwendung von Pfadausdrücken, aus denen automatisch ein Join gebildet wird: criteria.addequalsto("coctailgruppe.name, "Karibik ); Auch Sql-Funktionen können verwendet werden: criteria.addlike("upper(name),"%cola% ); Falls die Möglichkeiten trotzdem mal nicht ausreichen sollten, dann besteht auch die Möglichkeit direkt eine SQL-Bedingung anzuhängen: criteria.addsql("soundex(name) like '%' soundex('golladda')");

6 18. Deutsche ORACLE-Anwenderkonferenz Caching OJB bietet die Konfiguration verschiedener Caching-Strategien an (kann auch auf Tabellenebene konfiguriert werden): kein Cache Globaler Cache: Diese Variante ist mit Vorsicht zu genießen, da sie keinerlei Schutz vor konkurrierenden Zugriffen und keine Transaktionskonsistenz gewährleistet. Diese Variante wird aber defaultmäßig verwendet! Lokaler Cache pro PersistenceBroker: Das kam bei uns zum Einsatz, bei einer Web-Anwendung hat dies aber zur Folge, dass die Lebensdauer des Caches auf den Aufbau einer Webseite beschränkt ist und daher nur wenig gecachet wird. Zweistufiger Cache: Hier werden angeforderte Objekte aus dem globalen Cache zunächst in den lokalen Cache kopiert. Erst beim commit der Transaktion werden diese wieder zurückkopiert in den globalen Cache. Dies ist sicherlich gegenüber dem globalen Cache die wesentlich robustere Variante. Man sollte sich aber Gedanken machen über eine korrekt implementierte copy-semantik für die verwendeten Objekte. Verteilter Cache für Cluster-Konfigurationen Forms / J2 EE Application Server Vergleich mit anderen OR-Mapping-Tools Außer OJB sind auch Hibernate und Toplink (Oracle) verbreitete OR-Mapping-Tools für Java (es gibt aber auch noch zahlreiche andere). Alle drei verfügen im Grunde genommen über relativ ähnliche Features. Toplink glänzt mit einer komfortablen grafischen Benutzeroberfläche. Hibernate hat vermutlich die etwas größere Benutzergemeinde. OJB hat wohl die etwas elegantere, erweiterbarere Architektur. Erfahrungswerte Beim Einsatz in verschiedenen Projekten haben sich folgende Vor/Nachteile herauskristallisiert: Vorteile: Funktioniert sehr zuverlässig. Klassen müssen nicht von bestimmten Superklasen oder Interfaces abgeleitet werden, auch in Bezug auf das Datenmodell ist OJB nicht-invasiv Über zahlreiche Schnittstellen können verschiedene Aspekte an eigene Aspekte angepasst werden. (z.b. spezielles Mapping für eigene Datentypen, eigene Primärschlüsselgenerierung) Nachteile: Die Dokumentation könnte z.t. etwas ausführlicher sein. Die Fehlermeldungen sind manchmal nicht besonders aussagekräftig. Kontaktadresse: Daniel Blonski Donnersbergweg 3 D Ludwigshafen Telefon: +49(0) Fax: +49(0) daniel.blonski@she.net Internet: