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.

Tabelle 1. Einschränkungen des EJB-Programmiermodells mit EJB DMS. 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.

Symbol, das den Typ des Artikels anzeigt. Referenzartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rejb_ejbmedpcon
Dateiname:rejb_ejbmedpcon.html