Mit Scripting asynchrone EJB-Methoden konfigurieren
Verwenden Sie wsadmin-Scripting, um asynchrone EJB-Methoden (Enterprise JavaBeans) zu konfigurieren.
Vorbereitende Schritte
Informationen zu diesem Vorgang
Vorgehensweise
- Starten Sie das Scripting-Tool wsadmin mit der Scriptingspreche Jython.
- Stellen Sie fest, welche Attribute des Konfigurationsobjekts EJBAsync aktualisiert werden müssen. Folgende Attribute des
Konfigurationsobjekts EJBAsync können aktualisiert werden:
Tabelle 1. Attribute des Konfigurationsobjekts EJBAsync. In der folgenden Tabelle sind die Attribute des Konfigurationsobjekts EJBAsync beschrieben. Attribut Beschreibung max_Threads Gibt die maximale Anzahl an Threads an, die für die Ausführung asynchroner EJB-Methoden verwendet werden. Der Standardwert ist 5.
workReqQSize Gibt die Größe der Warteschlange für Verarbeitungsaufträge an. Die Warteschlange für Verarbeitungsaufträge ist ein Puffer, der angeforderte asynchrone Methoden puffert, bis ein Thread verfügbar ist, in dem die Anforderung ausgeführt werden kann. Die Summe aus den Attributen maxThreads und workReqQSize ist die zulässige Gesamtanzahl in Bearbeitung befindlicher Methodenanforderungen.
Wenn maxThreads beispielsweise auf 5 Threads gesetzt ist und workReqQSize auf 50, ist die zulässige Gesamtanzahl in Bearbeitung befindliche Methodenanforderungen 55.
Der Standardwert ist 0 und gibt an, dass die Warteschlangengröße von der Laufzeitumgebung verwaltet wird. Die Laufzeitumgebung verwendet derzeit den Wert 20 bzw. den Wert von maxThreads, je nachdem, welcher Wert höher ist.
workReqQFullAction Die Aktion, die ausgeführt wird, wenn der Thread-Pool ausgeschöpft und die Warteschlange für Verarbeitungsaufträge voll ist. Wenn Sie dieses Attribut auf 1 setzen, wird eine Ausnahme ausgelöst und nicht auf einen verfügbaren Thread oder einen verfügbaren Platz in der Warteschlange gewartet.
Wenn Sie dieses Attribut auf 0 setzen, wird gewartet, bis ein Thread oder ein Platz in der Warteschlange verfügbar ist, um die asynchrone Methode auszuführen.
Der Standardwert ist "0".
customWorkManagerJNDIName Gibt den JNDI-Namen (Java™ Naming and Directory Interface) an, der für die Suche des angepassten Arbeitsmanagers im Namespace verwendet wird. Der Standardwert ist null.
useCustomDefinedWM Gibt an, ob eine angepasste Arbeitsmanagerinstanz oder die interne Standardarbeitsmanagerinstanz verwendet wird. Wenn das Attribut useCustomDefinedWM auf true gesetzt ist, wird eine angepasste Arbeitsmanagerinstanz verwendet. In dem Fall muss das Attribut customWorkManagerJNDIName gesetzt sein. Alle anderen Attribute werden ignoriert.
Wenn das Attribut "useCustomDefinedWM" auf false gesetzt ist, wird die interne Arbeitsmanagerinstanz verwendet. In dem Fall wird das Attribut customWorkManagerJNDIName ignoriert. Alle anderen Attribute werden verwendet, um die Standardarbeitsmanagerinstanz zu konfigurieren.
Der Standardwert ist "false".
futureTimeout Gibt an, nach wie viel Sekunden das zukünftige serverseitige Objekt verfügbar ist, das als Ergebnis der Ausführung einer asynchronen Methode vom Typ "fire and return" erstellt wird. Das zukünftige serverseitige Objekt ist ungültig, wenn Sie die Methode get() aufrufen und ein Wert an den fernen Client zurückgegeben wird. Zur Vermeidung von Speicherverlusten müssen Sie die Methode get() für das zukünftige Objekt aufrufen oder für die Dauer des zukünftigen Objekts einen positiven Wert ungleich null angeben. Die Dauer null für das zukünftige Objekt gibt an, dass für das Objekt kein Zeitlimit gilt.
Der Standardwert ist 86400, d. h., nach 24 Stunden läuft das künftige Objekt ab und wird vom Anwendungsserver bereinigt. Danach ist das Objekt nicht mehr verfügbar.
Wenn nach Ablauf des zukünftigen Objekts die Methode get() aufgerufen wird, wird eine Ausnahme org.omg.CORBA.OBJECT_NOT_EXIST ausgelöst.
Unterstützte Konfigurationen: Dieser Wert ist nur für Clients gültig; die die Enterprise-Bean über eine ferne Geschäftsschnittstelle aufrufen. Der Wert wird für lokale Geschäftsschnittstellen und Sichten ohne Schnittstellen nicht verwendet. Nach Abschluss der asynchronen Arbeit setzt der Server einen Alarm für die im serverseitigen zukünftigen Objekt angegebene Dauer. Wenn der Alarm aktiviert wird, gibt der Server alle Ressourcen frei, die dem zukünftigen Objekt zugeordnet sind, woraufhin das Objekt dem Client nicht mehr zur Verfügung steht. Wenn der Client die Methode "get()" vor Ablauf der Zeit für das zukünftige Objekt aufruft, wird der Alarm abgebrochen, und alle Ressourcen, die dem künftigen Objekt zugeordnet sind, werden freigegeben.sptcfg
Unterstützte Konfigurationen: Dieses Attribut kann sich auf die Anzahl zukünftiger Objekte auf dem Server auswirken. Bestimmen Sie mit dem PMI-Statistikwert AsynchFutureObjectCount die Anzahl offener FutureObjects auf dem Server, um besser feststellen zu können, ob Anwendungen zukünftige Objekte ansammeln, ohne die Methode get() für diese Objekte aufzurufen. Weitere Informationen finden Sie unter "EJB-Zähler".sptcfg
- Fordern Sie eine Referenz auf das richtige EJBAsync-Konfigurationsobjekt an und speichern Sie
sie in einer Variablen.
Mit Jacl:
set async [$AdminConfig list EJBAsync]
Mit Jython:
async = AdminConfig.list('EJBAsync')
Wenn Sie in einer Umgebung mit mehreren Servern arbeiten, werden mehrere EJBAsync-Konfigurationsobjekte zurückgegeben. Gehen Sie die Liste wiederholt programmgesteuert durch, und wählen Sie das EJBAsync-Konfigurationsobjekt für den Server aus, den Sie aktualisieren müssen.
In einer Umgebung mit mehreren Servern können Sie alternativ zum wiederholten programmgesteuerten Durchgehen der Liste mit EJBAsync-Objekten manuell das richtige EJBAsync-Objekt auswählen, dieses kopieren und es dann in Ihre Variable einfügen.
Die Ausgabe des Befehls AdminConfig list könnte wie folgt aussehen:
(cells/myNode04Cell/nodes/myCellManager01/servers/dmgr|server.xml#EJBAsync_1)(cells/myNode04Cell/nodes/myNode04/servers/server1|server.xml#EJBAsync_1247498700906)
Sie können die Referenz auf das benötigte EJBAsync-Objekt kopieren und in Ihre Variable einfügen.
Mit Jacl:
set async "(cells/myNode04Cell/nodes/myNode04/servers/server1|server.xml#EJBAsync_1247498700906)"
Mit Jython:
async = "(cells/myNode04Cell/nodes/myNode04/servers/server1|server.xml#EJBAsync_1247498700906)"
- Aktualisieren Sie die Attribute für das Konfigurationsobjekt EJBAsync.
Aktualisieren Sie die Attribute für das EJBAsync-Konfigurationsobjekt mit dem Befehl AdminConfig modify. Geben Sie als Eingabe für den Befehl die im vorherigen Schritt angeforderte EJBAsync-Referenz an sowie eine Liste mit Attributname-Attributwert-Kombinationen.
Gehen Sie wie folgt vor, um die maximale Threadanzahl auf 10, eine Warteschlangengröße von 15 und einen futureTimeout-Wert von 3600 Sekunden festzulegen:
Mit Jacl:
set update "{maxThreads 10} {workReqQSize 15} {futureTimeout 3600}" $AdminConfig modify $async $update
Mit Jython:
AdminConfig.modify(async, '[ [maxThreads "10"] [workReqQSize "15"] [futureTimeout "3600"] ]')
- Speichern Sie die Konfigurationsänderungen.
Mit Jython:
AdminConfig.save()
Mit Jacl:
$AdminConfig save
- Synchronisieren Sie den Knoten. Dies gilt nur für eine
Network-Deployment-Umgebung.
Mit Jacl:
set sync1 [$AdminControl completeObjectName type=NodeSync,node=<Ihr Knoten>,*] $AdminControl invoke $sync1 sync
Mit Jython:
sync1 = AdminControl.completeObjectName('type=NodeSync,node=<Ihr Knoten>,*') AdminControl.invoke(sync1, 'sync')
Wenn Sie die Knotensynchronisation in diesen Beispielen durchführen, muss eine Verbindung zum Server bestehen.
Ergebnisse


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=txml_ejbAsynch_config
Dateiname:txml_ejbAsynch_config.html