Arbeitsmanager

Ein Arbeitsmanager stellt das Threading für Java™ EE-Anwendungen (Java Platform, Enterprise Edition) bereit.

Über die Administrationskonsole kann ein Administrator eine beliebige Zahl von Arbeitsmanagern konfigurieren. Der Administrator gibt die Eigenschaften des Arbeitsmanagers an, einschließlich der Richtlinie für die Vererbung von Java EE-Kontexten für Tasks, die an den Arbeitsmanager übergeben werden. Der Administrator bindet jeden Arbeitsmanager an eine eindeutige Position im JNDI (Java Naming and Directory Interface). Sie können Work-Manager-Objekte in jeder der folgenden Schnittstellen verwenden:
  • Verwaltete Steuerprogramme
    • javax.enterprise.concurrent.ManagedExecutorService
    • javax.enterprise.concurrent.ManagedScheduledExecutorService
    • java.util.concurrent.ExecutorService
    • java.util.concurrent.ScheduledExecutorService
  • Thread-Factorys
    • javax.enterprise.concurrent.ManagedThreadFactory
    • java.util.concurrent.ThreadFactory
  • Threadkontextservice
    • javax.enterprise.concurrent.ContextService
  • Asynchrone Beans
    • com.ibm.websphere.asynchbeans.WorkManager
  • CommonJ-Work-Manager
    • commonj.work.WorkManager
Der ausgewählte Schnittstellentyp wird während der JNDI-Lookup-Operation basierend auf dem Wert, den Sie in der Ressourcenumgebungsreferenz angeben, aufgelöst.

Die Arbeitsmanager stellen ein Programmiermodell für die Java EE-Anwendungen bereit. Nähere Informationen finden Sie im Abschnitt "Programmiermodell".

Fehler vermeiden Fehler vermeiden: Die Klasse javax.resource.spi.work.WorkManager ist eine Java-Schnittstelle, die für die Verwendung durch JCA-Ressourcenadapter (Java EE Connector Architecture) bestimmt ist. Dabei handelt es sich nicht um eine echte Implementierung des Arbeitsmanager, der von Java EE-Anwendungen verwendet wird.gotcha

Beim Schreiben einer Web- oder EJB-Komponente (Enterprise JavaBeans), die Concurrency Utilities for Java EE oder asynchrone Beans verwendet, muss der Entwickler in jede Komponente, die auf ein verwaltetes Steuerprogramm, eine Thread-Factory, einen Kontextservice oder einen Arbeitsmanager zugreifen muss, eine Ressourcenumgebungsreferenz aufnehmen. Weitere Informationen zu Ressourcenreferenzen finden Sie im Artikel "Referenzen". Die Komponente sucht anhand eines logischen Namens im Namespace "java:comp" der Komponente nach einem verwalteten Steuerprogramm, einer Thread-Factory, einem Kontextservice oder einem Arbeitsmanager, so wie sie nach einer Datenquelle, einer Enterprise-Bean oder einer Verbindungsfactory suchen würde.

Bei der Anwendungsimplementierung bindet der Implementierer physische Arbeitsmanager an logische Ressourcenumgebungsreferenzen (verwaltete Steuerprogramme, Thread-Factorys, Kontextservices oder Arbeitsmanager).

Beispiel: Angenommen, ein Entwickler benötigt drei Thread-Pools, um die Arbeit auf die Ebenen Bronze, Silber und Gold zu verteilen. Der Entwickler definiert die Komponente in der Weise, dass sie auf der Grundlage eines Attributs im Profil der Clientanwendung einen logischen Pool auswählt. Der Deployer hat die Möglichkeit zu entscheiden, wie diese Anforderung für drei Thread-Pools zugeordnet wird. Bei einem kleinen System könnte der Implementierer sich dafür entscheiden, einen einzelnen Thread-Pool zu verwenden. In diesem Fall bindet der Deployer alle drei Ressourcenreferenzen an dieselbe Instanz des Arbeitsmanagers (d. h. an denselben JNDI-Namen). Bei einem großen System könnten drei Thread-Pools unterstützt werden, sodass der Implementierer jede Ressourcenreferenz an einen anderen Arbeitsmanager bindet. Arbeitsmanager können von mehreren Java EE-Anwendungen, die auf demselben Server installiert sind, gemeinsam benutzt werden.

Ein Anwendungsentwickler kann so viele logische Ressourcenumgebungsreferenzen wie nötig verwenden. Der Implementierer entscheidet, ob dem logischen verwalteten Steuerprogramm, der logischen Thread-Factory, dem logischen Kontextservice oder dem logischen Arbeitsmanager, das bzw. die bzw. der in der Anwendung definiert ist, ein oder mehrere physische Arbeitsmanager zugeordnet werden.

Alle Java EE-Komponenten, die asynchrone Bereichsobjekte gemeinsam verwenden müssen, müssen denselben Arbeitsmanager verwenden. Diese Bereichsobjekte haben eine Affinität zu einem einzigen Arbeitsmanager. Eine Anwendung, die asynchrone Bereiche verwendet, sollte sicherstellen, dass alle Komponenten, die Bereichsobjekte verwenden, auch denselben Arbeitsmanager verwenden.

Sind mehrere Arbeitsmanager definiert, werden die zugrunde liegenden Thread-Pools nur dann in einer Java Virtual Machine (JVM) erstellt, wenn eine Anwendung in dieser JVM nach dem Arbeitsmanager sucht. Beispielsweise ist es möglich, dass zehn Thread-Pools (Arbeitsmanager) definiert sind, jedoch keiner tatsächlich erstellt wird, bevor nicht eine Anwendung danach sucht.

Wichtig: Work Manger unterstützen nicht die Übergabe von Arbeitsvorgängen an ferne JVMs.

Arbeitsmanager von CommonJ

Der Arbeitsmanager von CommonJ enthält eine Teilmenge der Methoden des Arbeitsmanagers für asynchrone Beans. Der Arbeitsmanager von CommonJ funktioniert zwar in einer Java EE-1.4-Umgebung, die Schnittstelle gibt aber nicht bei jeder JNDI-Lookup-Operation eine neue Instanz zurück, da diese Spezifikation nicht in der Java EE-Spezifikation enthalten ist.

Das optionale Feature der Spezifikation CommonJ Work für die Ausführung von Vorgängen oder Arbeitseinheiten über Remote-Zugriff wird nicht unterstützt. Selbst wenn eine Arbeitseinheit die Schnittstelle java.io.Serializable implementiert, wird die Arbeitseinheit nicht fern ausgeführt.

Verwaltetes Steuerprogramm suchen

Eine Anwendung kann wie folgt nach einem verwalteten Steuerprogramm suchen. Hier enthält die Komponente eine Ressourcenumgebungsreferenz mit dem Namen concurrent/myExecutor, die bei der Implementierung der Komponente an einen physischen Arbeitsmanager gebunden wurde:
InitialContext ic = new InitialContext();
ManagedExecutorService executor = (ManagedExecutorService) ic.lookup("java:comp/env/concurrent/myExecutor");

Vererbung von Java EE-Kontexten

Tasks, die an verwaltete Steuerprogramme und Arbeitsmanager übergeben werden, können die folgenden Java EE-Kontexte vom übergebenden Thread übernehmen. Kontext-Proxys können die Kontexttypen von dem Thread, der den Kontextservice zur Erstellung des Kontext-Proxys aufruft, übernehmen. Threads verwalteter Thread-Factorys können diese Kontexttypen von dem Thread, der die verwaltete Thread-Factory sucht oder injiziert, übernehmen.
Internationalisierungskontext
Wenn diese Option ausgewählt und der Internationalization Service aktiviert ist, ist der im Planungsthread vorhandene Internationalisierungskontext im Zielthread verfügbar.
Arbeitsbereich
Wenn diese Option ausgewählt ist, ist der Arbeitsbereichskontext für jede Arbeitsbereichspartition, die im Planungsthread vorhanden ist, im Zielthread verfügbar.
Anwendungsprofil (veraltet)
Der Kontext des Anwendungsprofils wird nicht unterstützt und ist für die meisten Anwendungen nicht verfügbar. Wenn diese Option für Java EE-1.3-Anwendungen ausgewählt ist, ist der Service für die Erstellung von Anwendungsprofilen aktiviert und die Serviceeigenschaft 5.x-Kompatibilitätsmodus ist ausgewählt. Die dem Planungsthread zugeordnete Application-Profiling-Task ist im Zielthread für Java EE-1.3-Anwendungen verfügbar. Für Java EE-1.4-Anwendungen oder Anwendungen höherer Versionen ist die Task für die Erstellung von Anwendungsprofilen eine Eigenschaft der zugehörigen Arbeitseinheit und nicht des Threads. Diese Option hat keine Auswirkung auf das Verhalten der Task in Java EE-1.4-Anwendungen oder Anwendungen höherer Versionen. Die geplante Arbeit, die in einer Java EE-1.4-Anwendung ausgeführt wird, empfängt vom Planungs-Thrad keine Profiling-Task.
Sicherheit
Die Task kann anonym oder als authentifizierter Client auf dem Thread, der sie erstellt und übergeben hat, ausgeführt werden. Dies ist hilfreich, weil die Task nur das tun kann, was das aufrufende Programm tun kann, und es ist besser als die Verwendung eines RUN_AS-Mechanismus, der ein solches Verhalten verhindert. Wenn Sie die Option Sicherheit auswählen, ist das JAAS-Subjekt aus dem Planungsthread im Zielthread verfügbar. Wenn Sie diese Option nicht auswählen, wird der Thread anonym ausgeführt.
Metadaten der Komponente
Die Metadaten der Komponente sind nur dann relevant, wenn die Task ein einfaches Java-Objekt ist. Handelt es sich bei der Task um eine Java EE-Komponente, z. B. um eine Enterprise-Bean, dann sind die Metadaten der Komponente aktiv.

Welche Kontexte übernommen werden können, ist abhängig von dem Arbeitsmanager, den die Anwendung, die die Task erstellt und übergibt, verwendet. Über die Administrationskonsole definiert der Administrator die permanente Kontextrichtlinie eines Arbeitsmanager, indem er die Services auswählt, für die der Arbeitsmanager zur Verfügung stehen soll.

Programmiermodell

Arbeitsmanager unterstützen die folgenden Programmiermodelle.
  • Concurrency Utilities for Java EE. Die Java EE-Spezifikation standardisiert dieses Programmiermodell, das verwaltete Steuerprogramme, verwaltete geplante Steuerprogramme und verwaltete Thread-Factorys umfasst, die die Struktur der vertrauten Java SE-API java.util.concurrent übernehmen. Sie umfasst auch den Kontextservice, der keine Entsprechung in der API java.util.concurrent hat.
  • Asynchrone Beans. Die folgenden Komponenten, die von asynchronen Beans derzeit verwendet werden, gehören zum Programmiermodell für asynchrone Beans: Arbeitsmanager, Ereignisquelle, asynchrone Bereiche, Subsystemmonitore und Java EE-Kontextschnittstellen.
  • CommonJ-Spezifikation. Das CommonJ-Programmiermodell verwendet WorkManager und TimerManager, um Threads und Zeitgeber in der Java EE-Umgebung asynchron zu verwalten.

Weitere Informationen zu verwalteten Steuerprogrammen, Thread-Factorys, Kontextservices und Work-Manager-APIs finden Sie in der Javadoc.

Beispiele für Parallelität

Tabelle 1. Verwaltetes Steuerprogramm oder Arbeitsmanager suchen
Verwaltetes Steuerprogramm Asynchrone Beans CommonJ
InitialContext ctx = new InitialContext();
ManagedExecutorService executor =
(ManagedExecutorService)
   ctx.lookup("java:comp/env/wm/myWorkMgr");
InitialContext ctx = new InitialContext();
com.ibm.websphere.asynchbeans.WorkManager wm  =
(com.ibm.websphere.asynchbeans.WorkManager)
   	       ctx.lookup(“java:comp/env/wm/MyWorkMgr”);
InitialContext ctx = new InitialContext();
commonj.work.WorkManager wm = (commonj.work.WorkManager)
   	       ctx.lookup(“java:comp/env/wm/MyWorkMgr”);
Tabelle 2. Task erstellen
Verwaltetes Steuerprogramm Asynchrone Beans CommonJ
 public class MyWork implements Callable<Integer> {
     public Integer call() {
       	     System.out.println(“Running.....”);
       return 1;
     }
   }
public class MyWork implements 
com.ibm.websphere.asynchbeans.Work {
   public void release() {
            ......
   }
   	   public void run() {
    	     System.out.println(“Running.....”);
}
public class MyWork implements 
commonj.work.Work{
   	   public boolean isDaemon() {
       return false;
   }
   	   public void release () {
        .....
   }
    	  public void run () {
     	     System.out.println(“Running.....”);
  }
Tabelle 3. Task übergeben
Verwaltetes Steuerprogramm Asynchrone Beans CommonJ
	MyWork work1 = new MyWork();
	MyWork work2 = new MyWork();

	// Fall 1: Blockieren, bis alle Vorgänge abgeschlossen sind
Collection<MyWork> tasks =
    Arrays.asList(work1, work2);
List<Future<Integer>> futures =
    executor.invokeAll(tasks);
for (Future<Integer> future : futures)
    System.out.println("work data=" + future.get());

// Fall 2: 1000 Millisekunden auf den Abschluss jedes Vorgangs warten
Integer result = executor.invokeAny(
    tasks, 1, TimeUnit.SECONDS);
System.out.println("work data=" + result);
	MyWork work1 = new MyWork();
	MyWork work2 = new MyWork();

	WorkItem item1;
	WorkItem item2;
	Item1=wm.startWork(work1);
	Item2=wm.startWork(work2);
	
	// Fall 1: Blockieren, bis alle Vorgänge abgeschlossen sind
	ArrayList col1 = new ArrayList();
	Col1.add(item1);
	Col1.add(item2);
wm.join(col1, WorkManager.JOIN_AND, WorkManager.INDEFINITE);
	// Wenn die Vorgänge abgeschlossen sind
	System.out.println(“work1 data=”+work1.getData());
	System.out.println(“work2 data=”+work2.getData());
	
	// Fall 1 sollte vor Fall 2 ausgeführt werden
// Fall 2: 1000 Millisekunden auf den Abschluss jedes Vorgangs warten
	Boolean ret = wm.join(col1,
  WorkManager.JOIN_OR, 1000);
	MyWork work1 = new MyWork();
	MyWork work2 = new MyWork();
	
	WorkItem item1;
	WorkItem item2;
	Item1=wm.schedule(work1 );
	Item2=wm.schedule(work2);
	
	// Fall 1: Blockieren, bis alle Vorgänge abgeschlossen sind
	Collection col1 = new ArrayList();
	col1.add(item1);
	col1.add(item2);
	wm.waitForAll(col1, WorkManager.INDEFINITE);
	// Wenn die Vorgänge abgeschlossen sind
	System.out.println(“work1 data=”+work1.getData());
	System.out.println(“work2 data=”+work2.getData());
	
	// Fall 1 sollte vor Fall 2 ausgeführt werden
// Fall 2: 1000 Millisekunden auf den Abschluss jedes Vorgangs warten
Collection finished = wm.waitForAny(col1,1000);
	// Status der Arbeitsvoränge prüfen
if (finished != null) {
	  Iterator I = finished.iterator();
	  	  if (i.hasNext()) {
	     	     WorkItem wi = (WorkItem) i.next();
	      	      if (wi.equals(item1)) {
	        	        System.out.println(“work1 = “+ work1.getData());
	      	      } else if (wi.equals(item2)) {
	        	        System.out.println(“work1 = “+ work1.getData());
	      }
	  }
}
Tabelle 4. Verwaltetes geplantes Steuerprogramm, Alarmmanager oder Zeitgebermanager erstellen
Verwaltetes geplantes Steuerprogramm Asynchrone Beans CommonJ
InitialContext ctx = new InitialContext();
ManagedScheduledExecutorService executor =
  (ManagedScheduledExecutorService)
    ctx.lookup("java:comp/env/wm/MyWorkMgr");
InitialContext ctx = new InitialContext();
com.ibm.websphere.asynchbeans.WorkManager wm  =
    (com.ibm.websphere.asynchbeans.WorkManager)
      	       ctx.lookup(“java:comp/env/wm/MyWorkMgr”);	
	AsynchScope ascope;
Try {
  	  Ascope = wm.createAsynchScope(“ABScope”);
	} Catch (DuplicateKeyException ex)
{
   	   Ascope = wm.findAsynchScope(“ABScope”);
   ex.printStackTrace();
}

	// AlarmManager abrufen
	AlarmManager  aMgr= ascope.getAlarmManager();
InitialContext ctx = new InitialContext();
	Commonj.timers.TimerManager tm = (commonj.timers.TimerManager) ctx.lookup(“java:comp/env/tm/MyTimerManager”);
Tabelle 5. Task, Alarm oder Zeitgeber planen
Verwaltetes geplantes Steuerprogramm Asynchrone Beans CommonJ
// Task erstellen
Runnable task = new StockQuoteTask(
    “qqq”, “johndoe@example.com”);
ScheduledFuture<?> future =
     executor.schedule(task, 1, TimeUnit.MINUTES);

	// Feste Verzögerung: Ausführung der Task auf
 // 1 Minute ab dem aktuellen Zeitpunke planen
 // und danach jede Stunde wiederholen
ScheduledFuture<?> future =
    executor.scheduleWithFixedDelay(
        task, 1, 60, TimeUnit.MINUTES);

	// Festes Intervall: Verfallszeit für Zeitgeber auf
 // 1 Minute ab dem aktuellen Zeitpunkt planen und
 // danach jede Stunde wiederholen
ScheduledFuture<?> future =
    executor.scheduleAtFixedRate(
        task, 1, 60, TimeUnit.MINUTES);
	// Alarm erstellen
	ABAlarmListener listener = new ABAlarmListener();
	Alarm am = aMgr.create(listener, “SomeContext”, 1000*60);
// Zeitgeber erstellen
	TimerListener listener = new StockQuoteTimerListener(“qqq”, “johndoe@example.com”);
	Timer timer = tm.schedule(listener, 1000*60);
	
	// Feste Verzögerung: Verfallszeit für Zeitgeber
 // auf 60 Sekunden ab dem aktuellen Zeitpunkt planen
 // und danach jede Stunde wiederholen
	Timer timer = tm.schedule(listener, 1000*60, 1000*30);
	
	// Festes Intervall: Verfallszeit für Zeitgeber auf
 // 60 Sekunden ab dem aktuellen Zeitpunkt planen und
 // danach jede Stunde wiederholen
	Timer timer = tm.scheduleAtFixedRate(listener, 1000*60, 1000*30);

Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



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