Optimierung des EJB-Containers

Wenn Sie Anwendungen verwenden, die sich auf die Größe des EJB-Container-Cache auswirken, kann sich eine falsche Größeneinstellung auf die Leistung der Anwendungen auswirken. Die über Container realisierte Transaktionspersistenz (CMP) wird in diesem Artikel erläutert. Es ist aber wichtig, zu wissen, dass Entity-Beans in einem Modul der EJB Version 3.x nicht unterstützt werden.

Größe des EJB-Cache

Die Überwachung von Tivoli Performance Viewer (TPV) ist eine äußerst hilfreiche Methode, mit der Sie feststellen können, ob die Größe für den EJB-Container-Cache optimal für Ihre Anwendung eingestellt ist.

Wenn die Anwendung den Cache ausfüllt und damit Einträge aus dem Cache gelöscht werden müssen, zeigt Tivoli Performance Viewer eine hohe Anzahl an ejbStores()-Aufrufen und eine wahrscheinlich niedrigere Prozessorauslastung auf der Workstationmaschine an als erwartet.

Für alle Anwendungen, die Enterprise-Beans verwenden, muss diese Einstellung angepasst werden, wenn Sie mit der folgenden Formel ein höheres Ergebnis als 2000 berechnen.
EJB-Cachegröße = (höchste Anzahl der in einer Transaktion registrierten Entity-Beans der
Option B oder C * maximale Anzahl paralleler Transaktionen) +
(höchste Anzahl eindeutiger Entity-Beans der Option A, auf die nach Einschätzung
bei typischer Auslastung der Anwendung zugegriffen wird) +
(Anzahl der bei typischer Auslastung aktiven Stateful-Session-Beans) +
(Anzahl der bei typischer Auslastung verwendeten Stateless-Session-Beans)

Für diese Angaben gilt Folgendes: Entity-Beans der Option B und C werden nur für die Dauer der Transaktion, in der sie
registriert sind, im EJB-Cache gespeichert. Der erste Teil der Formel berechnet
deshalb die durchschnittlichen Anforderungen an den EJB-Cache für diese Art von Beans.

Entity-Beans der Option A werden unbegrenzt im EJB-Cache gespeichert und nur dann
aus dem Cache entfernt, wenn die Anzahl der im Cache zu speichernden Beans die
definierte Cachegröße übersteigt.
Wenn Ihre Anwendung schreibgeschützte Beans verwendet, behandeln Sie sie im Rahmen
dieser Leistungsberechnung als Beans der Option A.

Stateful-Session-Beans werden so lange im EJB-Cache gespeichert, bis sie von
der Anwendung entfernt werden oder sie ihr Sitzungszeitlimit erreichen.

Für jeden EJB-Typ wird nur eine Stateless-Session-Bean-Instanz im Cache gespeichert,
während die Methoden für diese Stateless-Session-Bean ausgeführt werden.
Wenn zwei oder mehr Methoden gleichzeitig für denselben Stateless-Session-Bean-Typ
implementiert werden, hat jede Methode eine eigene Bean-Instanz, aber es wird für
alle Instanzen nur eine Cacheposition verwendet.

Diese Formel berechnet den oberen Grenzwert für die maximal mögliche Anzahl von Enterprise-Beans, die im Anwendungsserver gleichzeitig aktiv sein können. Da der Cache des EJB-Containers im Hinblick auf die Leistung so erstellt wird, dass alle Beans Platz haben, wird die beste Leistung erzielt, wenn für die Cachegröße ein höherer Wert als das mit der obigen Formel errechnete Ergebnis definiert wird.

Sie können die Größe des EJB-Cache in der Administrationskonsole unter Server > Servertypen > WebSphere-Anwendungsserver > Servername > Einstellungen des EJB-Containers > Einstellungen des EJB-Cache festlegen.

Während Sie die EJB-Cachegröße anpassen, können Sie auch den Parameter "Verwaltungsthread für EJB-Container" für die Anforderungen Ihrer Anwendung optimieren. Der Verwaltungsthread wird von der Einstellung Bereinigungsintervall gesteuert. Diese Einstellung definiert, wie oft ein Dämonthread in Application Server aktiviert wird, um Bean-Instanzen aus dem Cache zu entfernen, die in der letzten Zeit nicht mehr verwendet wurden, und damit die Anzahl der Bean-Instanzen stets unterhalb des Wertes für die Cachegröße zu halten. Auf diese Weise ist der EJB-Container in der Lage, Einträge schnell im Cache zu speichern und dort zu suchen. Übernehmen Sie die Standardeinstellung für dieses Intervall. In einigen Situationen kann jedoch die Wahl eines kürzeren Intervalls von Vorteil sein.

Informationen zum Optimieren des EJB-Cache mit dem EJB-Cache-Trace-Service finden Sie im Artikel zur Optimierung des Caches und zur Verwendung des Trace-Service.

Optimierung von EJB-Stateful-Session-Beans

Das Zeitlimit für Stateful-Session-Beans wird je nach Version von WebSphere Application Server auf verschiedene Arten und mit verschiedenen Geltungsbereichen konfiguriert.

WebSphere Application Server Version 6.1 und früher unterstützt die Konfiguration eines Zeitlimits für Stateful-Session-Beans pro Bean in der Datei ibm-ejb-jar-ext.xmi.

WebSphere Application Server Version 7.0 unterstützt die Konfiguration eines Zeitlimits für Stateful-Session-Beans pro Bean in der Datei ibm-ejb-jar-ext.xmi für (EJB-2.x-Module) und in der Datei ibm-ejb-jar-ext.xml (für EJB-3.x-Module).

WebSphere Application Server Version 8.x unterstützt die Konfiguration eines Zeitlimits für Stateful-Session-Beans pro Bean in der Datei ibm-ejb-jar-ext.xmi (für EJB-2.x-Module) und in der Datei ibm-ejb-jar-ext.xml (für EJB-3.x-Module) sowie des XML-Elements "stateful-timeout" und der Annotation "@StatefulTimeout". Außerdem können Sie mit der Systemeigenschaft "com.ibm.websphere.ejbcontainer.defaultStatefulSessionTimeout" einen serverweiten (globalen) Zeitlimitwert für Stateful-Session-Beans konfigurieren.

Unterstützte Konfigurationen Unterstützte Konfigurationen: Bei IBM® Erweiterungs- und Bindungsdateien weicht der Name der XMI- oder XML-Datei ab, je nachdem, ob Sie eine Java™ EE-Anwendung bzw. ein Java EE-Modul vor oder nach Version 5 verwenden. Eine IBM Erweiterungs- bzw. Bindungsdatei heißt "ibm-*-ext.xmi" bzw. "ibm-*-bnd.xmi". Das Platzhalterzeichen "*" steht für den Typ der Erweiterungs- oder Bindungsdatei, z. B. "app", "application", "ejb-jar" oder "web". Es gelten die folgenden Bedingungen:
  • Für eine Anwendung oder ein Modul, die bzw. das Java EE vor Version 5 verwendet, muss die Dateierweiterung ".xmi" sein.
  • Für eine Anwendung oder ein Modul, die bzw. das Java EE ab Version 5 verwendet, muss die Dateierweiterung ".xml" sein. Wenn Dateien mit der Erweiterung ".xmi" in der Anwendung oder im Modul enthalten sind, werden diese vom Produkt ignoriert.

Ein Modul von Java EE Version 5 oder einer höheren Version kann jedoch in einer Anwendung, die Dateien einer älteren Java EE-Version als Version 5 enthält, koexistieren.

Die Dateien ibm-webservices-ext.xmi, ibm-webservices-bnd.xmi, ibm-webservicesclient-bnd.xmi, ibm-webservicesclient-ext.xmi und ibm-portlet-ext.xmi können die Dateierweiterung ".xmi" weiterhin verwenden.

sptcfg

Stateless-Session-Beans haben keinen Zeitlimitwert, weil sie keinen Dialogstatus haben und keinem bestimmten Client zugeordnet sind.

Sie können Rational Application Developer verwenden, um die Datei ibm-ejb-jar-ext.xmi zu aktualisieren, in der der Zeitlimitwert für statusabhängige Sitzungen für Beans in einem EJB-2.x-Modul konfiguriert wird. Weitere Informationen finden Sie in den Artikeln zum Definieren von Sitzungszeitlimiteinstellungen für eine Bean im Information Center von Rational Application Developer Information.

Der generierte XMI-Code zum Definieren eines Zeitlimits von 15 Minuten für Stateful-Session-Beans ist beispielsweise wie folgt:
<ejbExtensions xmi:type="ejbext:SessionExtension" xmi:id="SessionExtension_1"
  timeout="15">

Sie können die Datei ibm-ejb-jar-ext.xml ändern, um das Zeitlimit für statusabhängige Sitzungen für Beans in einem EJB-3.x-Modul festzulegen. Im Folgenden sehen Sie Beispielcode, der den Zeitlimitwert für statusabhängige Sitzungen für die Bean "myBean" auf 15 Minuten setzt:

<ejbExtensions xmi:type="ejbext:SessionExtension" xmi:id="SessionExtension"
  timeout="15">
    <enterpriseBean xmi:type="ejb:Session" href="META-INF/ejb-jar.xml#MyBean"/>
 </ejbExtensions>

Sie können das Zeitlimit für Stateful-Session-Beans mithilfe der Annotation "@StatefulTimeout" konfigurieren. Die Annotation "@StatefulTimeout" akzeptiert einen erforderlichen Parameter mit Wert, der die Länge des Zeitlimits angibt, und einen optionalen Parameter für die Einheit. Wenn der optionale Parameter für die Einheit nicht angegeben wird, wird die die Standardeinheit (Minuten) verwendet. Die Annotation "@StatefulTimeout" wurde in EJB 3.1 eingeführt.

Verwenden Sie beispielsweise die Annotation "@StatefulTimeout", um einen Zeitlimitwert von 100 Sekunden festzulegen:

@StatefulTimeout(value=100 unit=java.util.concurrent.TimeUnit.SECONDS)

Sie können das Zeitlimit für Stateful-Session-Beans mit dem XML-Element "stateful-timeout" im Implementierungsdeskriptor ejb-jar.xml konfigurieren. Das Element "stateful-timeout" wurde in EJB 3.1 eingeführt.

Mit dem folgenden Beispielcode wird der Zeitlimitwert auf 100 Sekunden gesetzt:

<stateful-timeout>
     <timeout>100</timeout>
     <unit>Seconds</unit>
</stateful-timeout>

Die Annotation "@StatefulTimeout" und das XML-Element "stateful-timeout" sind spezifikationsdefinierte Mechanismen für die Deklaration von Zeitlimitwerten Pro Bean (Einführung in EJB 3.1). Vor EJB 3.1 gab es keine spezifikationsdefinierte Methode für die Deklaration eines Stateful-Session-Bean-Zeitlimits pro Bean. Wenn Sie das XML-Element "stateful-timeout" oder die Annotation "@StatefulTimeout" verwenden, steht der Wert -1 für kein Bean-Zeitlimit, und der Wert 0 bedeutet, dass die Bean sofort entfernt werden kann.

Sie können das Stateful-Session-Bean-Zeitlimit mit der Systemeigenschaft "com.ibm.websphere.ejbcontainer.defaultStatefulSessionTimeout" auf globaler (serverweiter) Basis definieren. Die Zeiteinheit für com.ibm.websphere.ejbcontainer.defaultStatefulSessionTimeout sind Minuten. Der angegebene Wert muss 0 oder höher sein. Wenn ein ungültiger Wert angegeben wird, wird stattdessen der Standardwert von 10 Minuten verwendet. Der globale Zeitlimitwert kann nicht mit XML oder Annotationen konfiguriert werden. Der globale Zeitlimitwert gilt für alle Stateful-Session-Beans, die im Server ausgeführt werden, einschließlich der Stateful-Session-Beans in Modulen der EJB Versionen 2.x und 3.x.

In WebSphere Application Server Version 8.x haben die Zeitlimiteinstellungen auf Bean-Ebene Vorrang vor der serverweiten Zeitlimiteinstellung. Die serverseitige Zeitlimiteinstellung hat Vorrang vor dem Standardzeitlimit (nicht angegeben). Die folgende Vorrangregelung wird verwendet, um den Stateful-Session-Bean-Zeitlimitwert für eine Bean zu bestimmen, die in WebSphere Application Server Version 8.x ausgeführt wird:
  1. XML-Element "stateful-timeout"
  2. Annotation "@StatefulTimeout"
  3. ibm-ejb-jar-ext.xml oder ibm-ejb-jar-ext.xmi
  4. Systemeigenschaft "com.ibm.websphere.ejbcontainer.defaultStatefulSessionTimeout"
  5. Wenn Sie nicht explizit einen Wert auf Bean- oder Serverebene definieren, wird der Standardzeitlimitwert von 10 Minuten angewendet.

Dcom.ibm.websphere.ejbcontainer.poolSize

Wenn die Anwendung die meisten Bean-Instanzen im Pool verwendet, wird dies von Tivoli Performance Viewer angezeigt. Vergrößern Sie in einem solchen Fall die Bean-Pools, deren Kapazität erschöpft ist, indem Sie den angepassten Eigenschaften der JVM den folgenden Parameter hinzufügen:

-Dcom.ibm.websphere.ejbcontainer.poolSize=<Anwendungsname>#<Modulname>#
<Enterprise-Bean-Name>=<Mindestgröße>,<maximale_Größe>

Für diese Angaben gilt Folgendes:

Das Element <Anwendungsname> steht für den Namen der Java EE-Anwendung, der im Implementierungsdeskriptor der EJB-Datei für die Bean definiert ist, deren Poolgröße definiert wird.

Das Element <Modulname> steht für den Namen der JAR-Datei des EJB-Moduls für die Bean, deren Poolgröße definiert wird.

Das Element <Bean-Name> steht für den Namen der Java EE-Enterprise-Bean, der im Implementierungsdeskriptor des EJB-Moduls für die Bean definiert ist, deren Poolgröße definiert wird.

Das Element <Mindestgröße> steht für die Anzahl der Bean-Instanzen, die der Container im Pool verwaltet, unabhängig davon, wie lange die Beans bereits im Pool vorhanden sind. (Beans, die diesen Wert überschreiten, werden nach und nach aus dem Pool gelöscht, um die Speicherbelegung zu optimieren.)

Das Element <maximale_Größe> gibt die Anzahl der Bean-Instanzen im Pool an, bei deren Erreichen keine weiteren Bean-Instanzen in den Pool aufgenommen werden (d. h. sobald der Pool diese Größe erreicht, werden alle weiteren Beans verworfen und nicht mehr dem Pool hinzugefügt, wodurch sichergestellt wird, dass die Anzahl der Beans im Pool einen oberen Grenzwert hat, damit die Speicherbelegung nicht unbegrenzt zunimmt).

Um die Anzahl der Instanzen im Pool bei einer festen Größe zu halten, können die Elemente "Mindestgröße" und "Maximalgröße" auf denselben Wert gesetzt werden. Es ist ein separater Instanzenpool für jeden aktiven EJB-Typ im Anwendungsserver vorhanden, die zu Beginn jeweils leer sind. Die Anzahl der Instanzen steigt an, wenn Beans verwendet und anschließend in den Pool gestellt werden.

Wenn der Container eine Bean-Instanz benötigt und keine Beans im Pool verfügbar sind, erstellt der Container eine Bean-Instanz, verwendet diese und stellt diese Instanz dann in den Pool, sofern die maximale Anzahl an Instanzen im Pool noch nicht erreicht ist. Beispiel:
Dcom.ibm.websphere.ejbcontainer.poolSize=ivtApp#ivtEJB.jar#ivtEJBObject=125,1327  
Diese Anweisung definiert eine Mindestgröße von 125 und eine maximale Größe von 1327 Instanzen für die Bean "ivtEJBObject" in der Datei ivtEJB.jar in der Anwendung "ivtApp".

Die Anwendung "ivtApp" wird durch den tatsächlichen Anwendungsnamen ersetzt. Die Datei ivtEJB.jar durch die JAR-Datei ersetzt, die die Bean enthält, deren Poolgröße erhöht werden muss, und "ivtEJBObject" steht für den Bean-Namen der Enterprise-Bean, deren Poolgröße erhöht werden muss. Es werden mindestens 125 Beans im Pool gespeichert. Maximal werden 1327 Beans im Pool gespeichert. Legen Sie diese Werte so fest, dass keine weiteren Beans mehr aus dem Pool gelöscht werden. In den meisten Fällen müssen diese beiden Einstellungen auf denselben Wert gesetzt werden, wenn genügend Speicher verfügbar ist, weil der Pool dann weder vergrößert noch verkleinert wird.

Dcom.ibm.websphere.ejbcontainer.noPrimaryKeyMutation

Sie müssen wissen, wie Ihre Anwendungen die Erstellung von Primärschlüsselobjekten für CMP-Beans und BMP-Beans in Application Server behandeln.

Der IBM EJB-Container verwendet den Primärschlüssel einer Entity-Bean als ID in internen Datenstrukturen, um eine optimale Leistung zu erzielen. Allerdings muss der EJB-Container diese Primärschlüsselobjekte beim ersten Zugriff auf die Bean kopieren, um sicherzustellen, dass die in den internen Caches gespeicherten Objekte gesondert von den in einer Anwendung verwendeten Objekten verwaltet werden. Dieser Prozess gewährleistet die Konsistenz interner Strukturen, falls die Anwendung den Primärschlüssel ändert oder mutiert. Wenn die Anwendung nach dem Erstellen von Entity-Beans keinen der zum Erstellen und Aufrufen der Entity-Beans verwendeten Primärschlüssel ändert, können Sie ein spezielles Flag verwenden, das dem EJB-Container ermöglicht, das Kopieren des Primärschlüsselobjekts zu überspringen und somit Prozessorzyklen einzusparen und die Leistung zu verbessern. Dieser Mechanismus kann auf eigenes Risiko durch das Hinzufügen der folgenden –D-Eigenschaft zum Feld "Angepasste JVM-Eigenschaften" aktiviert werden.
-Dcom.ibm.websphere.ejbcontainer.noPrimaryKeyMutation=true
Unterstützte Konfigurationen Unterstützte Konfigurationen: Entity-Beans werden in Modulen der EJB Version 3.x und höher nicht unterstützt.sptcfg

Der Leistungsvorteil dieser Optimierung ist von der Anwendung abhängig. Wenn die Anwendung primitive Typen für die Primärschlüssel von Enterprise-Beans verwendet, können keine Vorteile erzielt werden, weil diese Objekte bereits unveränderlich sind und der Kopiermechanismus dies berücksichtigt. Wenn die Anwendung jedoch viele komplexe Primärschlüssel verwendet, d. h. ein Objekt für einen Primärschlüssel oder mehrere Felder, können Sie mit diesem Parameter eine signifikante Verbesserung erzielen.

Dcom.ibm.ws.pm.deferredcreate

Der Persistenzmanager wird vom EJB-Container verwendet, um Daten von CMP-Entity-Beans persistent in der Datenbank zu speichern.

Wenn Sie Entity-Beans mit der Methode ejbCreate() erstellen, fügt der Persistenzmanager unverzüglich die leere Zeile nur mit dem Primärschlüssel in die Datenbank ein. In den meisten Fällen müssen Sie nach dem Erstellen der Bean Felder in der erstellten Bean oder in anderen Beans in derselben Transaktion ändern. Wenn Sie das Einfügen in die Datenbank bis zum Ende der Transaktion verzögern möchten, damit eine Datenbankoperation weniger durchgeführt werden muss, können Sie dieses –D-Flag im Feld "Angepasste JVM-Eigenschaften" setzen. Die Daten werden in die Datenbank eingefügt, und die Konsistenz bleibt gewährleistet.
Unterstützte Konfigurationen Unterstützte Konfigurationen: Entity-Beans werden in Modulen der EJB Version 3.x und höher nicht unterstützt.sptcfg
-Dcom.ibm.ws.pm.deferredcreate=true

Der Leistungsvorteil dieser Optimierung ist von der Anwendung abhängig. Wenn die Transaktionen der EJB-Anwendung einfügeintensiv sind, kann die Anwendung von dieser Optimierung profitieren. Die Auswirkungen auf die Leistung sind wesentlich geringer, wenn die Anwendung nur sehr wenige Einfügeoperationen durchführt.

Dcom.ibm.ws.pm.batch

Wenn eine EJB-Anwendung in einer einzigen Transaktion auf mehrere CMP-Beans zugreift, entspricht die Anzahl der Operationen, die an die Datenbank abgesetzt werden, je nach Art der für die Beans ausgeführten Operationen (z. B. Aktualisierungs-, Einfüge- und Leseoperationen) direkt den für die CMP-Beans ausgeführten Operationen. Wenn das verwendete Datenbanksystem Stapel von Aktualisierungsanweisungen unterstützt, können Sie dieses Flag aktivieren und damit eine Leistungssteigerung bei allen Interaktionen mit der Datenbank erzielen, die mehr als zwei Aktualisierungen in einer Transaktion beinhalten.

Unterstützte Konfigurationen Unterstützte Konfigurationen: Entity-Beans werden in Modulen der EJB Version 3.x und höher nicht unterstützt.sptcfg
Verwenden Sie dieses Flag, das dem Persistenzmanager ermöglicht, alle Aktualisierungsanweisungen einer einzigen Stapelanweisung hinzuzufügen, die an die Datenbank übergeben wird. Bei diesem Prozess entfallen Umläufe zur Datenbank, was die Leistung verbessert. Wenn Sie wissen, dass Ihre Anwendung mehrere CMP-Beans in einer einzigen Transaktion aktualisiert, und die Datenbank Stapelaktualisierungen unterstützt, können Sie das Flag –D im Feld für die angepassten JVM-Eigenschaften setzen. Beispiel:
-Dcom.ibm.ws.pm.batch=true

Der Leistungsvorteil dieser Optimierung ist von der Anwendung abhängig. Wenn die Anwendung CMP-Beans nie oder nur sehr selten oder nur eine einzige Bean pro Transaktion aktualisiert, ist mit dieser Optimierung keine Leistungsverbesserung zu erzielen. Falls die Anwendung jedoch mehrere Beans pro Transaktion aktualisiert, ist die Verwendung dieses Parameters von Vorteil für die Leistung Ihrer Anwendungen.

Der folgenden Tabelle können Sie entnehmen, welche Back-End-Datenbanken Aktualisierungen im Stapelbetrieb unterstützen.
Tabelle 1. Back-End-Datenbanken, die Aktualisierungen im Stapelbetrieb unterstützen. Der folgenden Tabelle können Sie entnehmen, welche Back-End-Datenbanken Aktualisierungen im Stapelbetrieb unterstützen.
Datenbank Unterstützt Aktualisierung im Stapelbetrieb Unterstützt Aktualisierung im Stapelbetrieb mit optimistischer Parallelitätssteuerung
DB2 Ja Nein
Oracle Ja Nein
DB2 Universal Driver Ja Ja
Informix Ja Ja
SQLServer Ja Ja
Apache Derby Ja Ja
Unterstützte Konfigurationen Unterstützte Konfigurationen: Die Aktualisierung im Stapelbetrieb mit OCC kann nicht für Datenbanken ausgeführt werden, die dieses Feature nicht unterstützen. Dies gilt auch dann, wenn dies in der Zugriffsart angegeben ist. sptcfg

com.ibm.ws.pm.useLegacyCache

Gibt den Namen der Java-Klasse an, die das Produkt verwendet, um die Schnittstelle javax.rmi.CORBA.UtilDelegate zu implementieren.

Unterstützte Konfigurationen Unterstützte Konfigurationen: Entity-Beans werden in Modulen der EJB Version 3.x und höher nicht unterstützt.sptcfg
Der Persistenzmanager unterstützt zwei unterschiedliche Typen von Cachingmechanismen: den traditionellen Cache und den zweistufigen Cache. Normalerweise ist der zweistufe Cache aufgrund seiner Optimierungen in diesem Modus effizienter als der traditionelle Cache. Standardmäßig wird der traditionelle Cache verwendet, obwohl der zweistufige Cache empfohlen wird. Sie können diese Konfiguration mit der folgenden Systemeigenschaft definieren:
com.ibm.ws.pm.useLegacyCache=false

com.ibm.ws.pm.grouppartialupdate und com.ibm.ws.pm.batch

Das Feature für Teilaktualisierungen verbessert in bestimmten Szenarien die Leistung von Anwendungen mit Enterprise-Beans. Der Persistenzmanager unterstützt zwei unterschiedliche Typen von Cachingmechanismen: den traditionellen Cache und den zweistufigen Cache. Normalerweise bietet der zweistufe Cache aufgrund seiner Optimierungen in diesem Modus eine bessere Leistung als der traditionelle Cache.

Unterstützte Konfigurationen Unterstützte Konfigurationen: Entity-Beans werden in Modulen der EJB Version 3.x und höher nicht unterstützt.sptcfg
In bestimmten Anwendungen, in denen Sie sowohl Aktualisierungen im Stapelbetrieb als auch Teilaktualisierungen durchführen müssen, müssen Sie die folgenden Systemeigenschaften definieren, um die Vorteile beider Verfahren nutzen zu können:
'com.ibm.ws.pm.grouppartialupdate=true' und 'com.ibm.ws.pm.batch=true'

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=rprf_ejbcontainer
Dateiname:rprf_ejbcontainer.html