Programmierhinweise zum EJB Data Mediator Service
Wenn Sie damit beginnen, Ihre Anwendungen so zu schreiben, dass Sie von dem im Produkt bereitgestellten EJB Data Mediator Service (DMS) profitieren können, sollten Sie Folgendes beachten:
EJB-Programmiermodell
Der
EJB Data Mediator Service unterstützt nur einen Teil des EJB-Programmiermodells.
- Wenn Sie Daten von EJB-Instanzen mit EJB-Collection-Parametern abrufen oder EJB-Instanzen mit
applyChanges aktualisieren, gilt Folgendes:
- Der EJB DMS verwendet für Enterprise-Beans Local-Interfaces. Aufrufe von getter und setter für CMP-Felder müssen an das Local-Interface weitergeleitet werden. Dies gilt auch für alle in Abfrageausdrücken verwendeten EJB-Methoden.
- Wenn der Mediator eine EJB erstellen soll, muss es eine Methode create geben, die die Primärschlüsselklasse
als einziges für EJB-Home definiertes Argument method verwendet. Falls es keine solche Methode gibt, müssen Sie einen
Adapter für die Operation create angeben. Neben der Methode create muss
das für die EJB definierte Interface EJBLocalHome folgende Methode enthalten:
findByPrimaryKey(<Schlüsselklasse>) remove (java.lang.Object) create (<Schlüsselklasse>)
- Wenn die Methode applyChanges direkt für die Datenbank aufgerufen wird, geschieht Folgendes:
- Das Containerupdate wird umgangen. Sie sollten schnellstmöglich eine Aktualisierung erzwingen, indem Sie die Transaktion beenden und die entsprechenden Containercacheoptionen verwenden.
- Die Wartung der containergesteuerten Beziehungen (EJB-CMR) wird umgangen. Sie müssen sich für die Verwaltung von Beziehungen, die nicht in den DataGraph abgerufen wurden, auf die relationale Integrität der Datenbank verlassen.
- Die CMP-Felder müssen Felder eines zulässigen Typs sein. Eine Liste dieser Typen finden Sie im Artikel Abfragesyntax für EJB Mediator.
- CMP-Felder benutzerdefinierter Typen, die EJB-Umsetzer/Composer verwenden, werden nicht unterstützt.
In der folgenden Tabelle sind die Bedingungen des EJB-Programmiermodells aufgeführt, die vom EJB DMS nicht unterstützt werden.
Direkter Abruf aus der Datenbank | Abruf aus dem EJB-Container | Direkte Aktualisierung der Datenbank | Aktualisierung über EJB | |
---|---|---|---|---|
Vererbung der EJB-Persistenz | Nein | Nein | Nein | Nein |
EJB-CMP-Feld mit Umsetzer | Nein | Ja | Nein | Ja |
Transaktionsorientierung
- Alle Mediatoraufrufe, einschließlich create, müssen innerhalb einer Transaktion (einer Benutzer- oder einer Containertransaktion) ausgeführt werden. Die verschiedenen Mediatoraufrufe, einschließlich create, getGraph und applyChanges, müssen nicht in derselben Transaktion aufgerufen werden. Tatsächlich ist es so, dass die Aufrufe größtenteils in separaten Transaktionen durchgeführt werden.
Zugriffsart
- Wenn die Mediatorabfrage mit dem ASN (Abstract Schema Name) auf eine EJB verweist, werden die Daten direkt aus der Datenbank abgerufen. Die Zugriffsart (und die Isolationsstufe), der für die Datenquellenverbindung verwendet wird, ist die Zugriffsart, die im Anwendungsprofil als Zugriffsart für dynamische EJB-Abfragen definiert ist. Es wird empfohlen, eine optimistische Zugriffsart für Ihre Anwendung zu definieren, weil ein DataGraph für die Verwendung in einem Offlineprogrammiermodell bestimmt ist.
- Wenn der Mediator Daten über eine EJB-Sammlung abruft, wird die im Anwendungsprofil angegebene Zugriffsart verwendet, wenn die EJB aktiviert werden muss.
- Während der Ausführung von applyChanges wird eine optimistische Steuerung des gemeinsamen Zugriffs verwendet, um bestimmte Felder
im DataObject zu prüfen, bevor die Änderungen auf die Datenbank angewendet werden.
Aktualisierungen werden gewöhnlich in einer anderen Transaktion als Abrufe verarbeitet.
Um einen Verlust von Aktualisierungen zu vermeiden, ist es daher erforderlich sicherzustellen, dass keine andere
Transaktion die Daten aktualisiert hat.
Wenn Sie die EJB-RDB-Zuordnung definieren, können Sie ein oder mehrere EJB-Felder als optimistische Vergleichselemente angeben.
Die Felder werden für die Überprüfung verwendet: Der aktuelle Datenbankwert wird mit dem
alten Wert aus dem Änderungsprotokoll des DataGraph verglichen. Wenn die Überprüfung erfolgreich ist,
werden die aktuellen Werte der Felder in die Datenbank geschrieben.
Wenn der Vergleich false
zurückgibt und die Aktualisierung scheitert, tritt eine Ausnahme ein. All dies wird, wie im folgenden Beispiel gezeigt, mit einer
einzigen update-Anweisung mit zusätzlich hinzugefügten Vergleichselementen erreicht.
Das optimisticPredicate-Feld ist myColumn1.
update myTable set myColumn1="new value1", myColumn2="new value2"where myKey="key value" and myColumn1="old value1"
- Wird applyChanges über den EJB-Container ausgeführt, werden die aktuellen Werte der Enterprise-Beans mit den alten Werten der Felder für das Prädikat optimistic verglichen. Stimmen die Werte nicht überein, tritt eine Ausnahme ein.
- Sofern Sie ein oder mehrere EJB-Felder als optimisticPredicates definiert haben, muss mindestens eines der optmisticPredicate-Felder in das Datenobjekt abgerufen werden, damit der SDO aktualisiert werden kann. Andernfalls gibt applyChanges eine Ausnahme zurück. Das Feld sollte vom Aufrufenden oder einem Datenbankauslöser aktualisiert werden. Der Mediator kann den Wert nicht automatisch erhöhen oder das Feld setzen.
- Es werden nicht alle Felder geprüft, sondern nur die, die in der EJB-RDB-Zuordnung als optimisticPredicate gekennzeichnet sind.
- Das EJB-Zuordnungstool sieht auch die Möglichkeit vor, dass keine optimisticPredicate-Felder angegeben werden. In diesem Fall führt der Mediator die Aktualisierungen ohne Überprüfung durch.
- Für Erstellungs- und Löschoperationen werden die optimisticPredicate-Felder nicht verwendet.
- Wenn Sie Änderungen über EJB-Instanzen anwenden, muss die EJB möglicherweise zuerst aktiviert werden. In diesem Fall kommt die Zugriffsart zur Anwendung, der den EJB-Methoden zugeordnet ist. Es wird empfohlen, applyChanges in einem Profil mit pessimistischer Zugriffsart anzuwenden, da ansonsten die Logik für optimistische Steuerung des gemeinsamen Zugriffs zweimal aufgerufen wird: einmal, wenn die Werte des Datenobjekts in die EJB kopiert werden, und ein zweites Mal, wenn der Persistenzmanager die alten Werte der EJB-Felder mit dem Datenbanksatz vergleicht.
- Die Zugriffsart, die vom Mediator beim direkten Abruf aus der Datenbank verwendet wird, die Standardzugriffsart, die für die in der ersten Abfrageanweisung angegebene EJB definiert ist.
Empfohlene Methoden
- Sie können getGraph für eine Mediatorinstanz aufrufen, den zurückgegebenen DataGraph aktualisieren und dann applyChanges für eine andere Mediatorinstanz aufrufen. Obwohl für die Aufrufe nicht dieselbe Mediatorinstanz erforderlich ist, müssen die Aufrufe dennoch dieselbe Abfrageform verwenden. Die Abfrageform definiert die Anzahl und die Reihenfolge der Abfrageanweisungen, die in SELECT- und FROM-Klauseln angegebenen Felder und Beziehungen usw.
- Vermeiden Sie nach Möglichkeit wiederholte Aufrufe von createMediator. Verwenden Sie Abfragen mit mit Parameterangaben und übergeben Sie verschiedene Parameterwerte mit getGraph.