Methoden zur Taskverwaltung mit einem Scheduler
Der Scheduler stellt mehrere Methoden für die Taskverwaltung bereit.
- suspend()
- Setzt eine Task aus. Die Task wird so lange unterbrochen, bis sie wieder aufgenommen wird.
- resume()
- Nimmt eine zuvor ausgesetzte Task wieder auf.
- cancel()
- Bricht eine Task ab. Die Task wird nicht ausgeführt und kann nicht fortgesetzt werden.
- purge()
- Löscht eine abgebrochene Task permanent aus dem persistenten Speicher.
- getStatus()
- Gibt den aktuellen Status der Task zurück.
//Task erstellen.
TaskInfo taskInfo = ...
TaskStatus status = scheduler.create(taskInfo);
//Task-ID abrufen
String taskId = status.getTaskId();
//Task abbrechen. Flag purgeAlso angeben, damit die Task nicht im persistenten
//Speicher bleibt.
scheduler.cancel(taskId,true);
set jndiName sched/MyScheduler
# Den JNDI-Namen dem MBean-Namen zuordnen. Der MBean-Name wird gebildet, indem der
# Schrägstrich (/) im JNDI-Namen durch einen Punkt (.) ersetzt wird, dem
# die Angabe Scheduler_ vorangestellt wird.
regsub -all {/} $jndiName "." jndiNameset mbeanName Scheduler_$jndiName
puts "Looking-up Scheduler MBean $mbeanName"
set sched [$AdminControl queryNames WebSphere:*,type=WASScheduler,name=$mbeanName]
puts $sched
# ObjectName-Format der Scheduler-MBean abrufen
set schedO [$AdminControl makeObjectName $sched]
# TaskInfo-Objekt erstellen
# (Hier fehlt Code)
set params [java::new {java.lang.Object[]} 1]
$params set 0 $taskInfo
set sigs [java::new {java.lang.String[]} 1]
$sigs set 0 com.ibm.websphere.scheduler.TaskInfo
set taskStatus [java::cast com.ibm.websphere.scheduler.TaskStatus [$AdminControl invoke_jmx $schedO
create $params $sigs]]
set taskID [$taskStatus getTaskId]
puts "Task Created. TaskID= $taskID"
# Task mit der Task-ID aus dem TaskStatus-Objekt, das
# während der Erstellung zurückgegeben wurde, abbrechen
set params [java::new {java.lang.Object[]} 1]
$params set 0 false
set sigs [java::new {java.lang.String[]} 1]
$sigs set 0 java.lang.boolean
set taskStatus [java::cast com.ibm.websphere.scheduler.TaskStatus [$AdminControl invoke_jmx $schedO
cancel $params $sigs]]
Transaktionsunterstützung. Alle Methoden der Scheduler-API sind transaktionsorientiert. Falls ein globaler Transaktionskontext vorhanden ist, wird dieser für die Durchführung der Operation verwendet. Sollte eine unerwartete Ausnahme ausgelöst werden, wird die Transaktion für Rollback (rückgängig machen) gekennzeichnet, und der Aufrufende muss entsprechende Maßnahmen einleiten. Falls eine erwartete oder deklarierte Ausnahme ausgelöst wird, bleibt die Transaktion intakt, und der aufrufende Prozess muss die Transaktion rückgängig machen (Rollback) oder festschreiben (Commit). Wenn die Transaktion zu irgendeinem Zeitpunkt rückgängig gemacht wird, werden auch alle Scheduleroperationen, die in der Transaktion durchgeführt wurden, rückgängig gemacht.
Falls ein lokaler Transaktionskontext vorhanden ist, wird dieser ausgesetzt und ein neuer globaler Transaktionskontext gestartet. Ist kein Transaktionskontext aktiv, wird ebenfalls ein globaler Transaktionskontext gestartet. Sollte eine unerwartete Ausnahme ausgelöst werden, wird die Transaktion in beiden Fällen rückgängig gemacht. Wenn eine deklarierte Ausnahme ausgelöst wird, wird die Transaktion festgeschrieben.
Sollte ein anderer Thread die fragliche Task gleichzeitig ändern, wird eine Ausnahme vom Typ TaskPending ausgelöst. Diese Ausnahme wird ausgelöst, weil Scheduler die Datenbank optimistisch sperren. Die aufrufende Anwendung kann dann versuchen, die Operation zu wiederholen.
Funktionen für die Taskverwaltung können blockieren, wenn die Task ausgeführt wird. Da der Scheduler garantiert, dass jede Task nur einmal ausgeführt wird, muss die Task für die Dauer einer aktiven Task gesperrt werden. Wenn eine Task mit einer der Verwaltungsfunktionen geändert wird, aber die globale Transaktion noch nicht festgeschrieben ist, werden alle anderen Verwaltungsfunktionen, die von einer anderen Transaktion für diese Task abgesetzt werden, ebenfalls blockiert.
Die Methode TaskHandler.process() einer Task für Session-Beans ohne Status (Stateless-Session-Bean) kann ihren eigenen Status ändern. Die Task muss jedoch in derselben Transaktion wie der Scheduler ausgeführt werden. Deshalb kann eine aktive Task sich selbst nur dann ändern, wenn sie die CMT-Typen (Container-Managed Transaktion) Required und Mandatory verwendet. Wenn in der Methode process() der Transaktionstyp Requires New angegeben ist, sind alle Verwaltungsfunktionen gesperrt.
Alle in der Scheduler-API definierten Methoden sind in der API-Dokumentation beschrieben.