Zeitgeber mit dem EJB-Zeitgeberservice für Enterprise-Beans erstellen

Wenn Sie vom EJB-Zeitgeberservice für die Planung zeitbasierter Ereignisse profitieren möchten, können Sie Enterprise-Beans verwenden.

Informationen zu diesem Vorgang

Im Rahmen der Unterstützung für die Spezifikation EJB 3.1 können Sie nicht persistente EJB-Zeitgeber erstellen. Dieses Produkt unterstützt zudem die erweiterte API TimerService für eine programmgesteuerte Erstellung von Zeitgebern. Darüber hinaus können Sie den EJB-Container so konfigurieren, dass er automatisch einen Zeitgeber erstellt, wenn die Anwendung gestartet wird.

WebSphere Application Server implementiert den EJB-Zeitgeberservice. Basierend auf Ihren Geschäftsanforderungen, können Sie persistente oder nicht persistente Zeitgeber verwenden. Persistente Zeitgeber sind hilfreich, wenn Sie einen Zeitgeber für ein zeitbasiertes Ereignis erstellen, das die Zusicherung der Zeitgeberexistenz über den Lebenszyklus des Servers hinweg erfordert. Bereits gestartete persistente Zeitgeber werden automatisch gestartet, wenn Ihr Server gestartet wird, und bleiben auch dann bestehen, wenn der Server beendet und neu gestartet wird. Persistente Zeitgeber können Sie beispielsweise nutzen, um eine Systemanwendung zu starten oder eine Statusbenachrichtigung beim Ablauf eines Zeitgebers zu senden. Nicht persistente Zeitgeber sind in unkritischen Situationen hilfreich, in denen die Zeitgeberaktionen ohne negativen Einfluss auf die Geschäftsabläufe übergangen oder wiederholt werden können. Dies trifft beispielsweise auf das Abfragen einer Temperatur zu.

Sie können Zeitgeber programmgesteuert erstellen. Zeitgeber können aber auch automatisch erstellt werden. Dafür wird die Annotation "@Schedule" in der Bean-Klasse oder das Element "timer" im Implementierungsdeskriptor "ejb-jar.xml" verwendet. Bei automatischer Erstellung von Zeitgebern können Sie einen Zeitgeber planen, ohne sich darauf verlassen zu müssen, dass Ihre Enterprise-Bean aufgerufen wird, um programmgesteuert eine Erstellungsmethode des EJB-Zeitgeberservice zu starten.

Persistente Zeitgeber

Persistente Zeitgeber werden als Scheduler-Service-Tasks implementiert. Standardmäßig wird eine interne oder vorkonfigurierte Schedulerinstanz für die Verwaltung dieser Tasks verwendet. Die Einstellungen werden persistent in einer Apache-Derby-Datenbank gespeichert, die dem Serverprozess zugeordnet ist.

Für die interne Schedulerinstanz können Sie Basisanpassungen vornehmen. Informationen zur Anpassung der Schedulerinstanz finden Sie im Abschnitt zum Konfigurieren eines Zeitgeberservice.

Das Erstellen und Aufheben von Zeitgebern ist transaktionsorientiert und persistent. Wenn ein Zeitgeber in einer Transaktion erstellt wird und diese Transaktion später rückgängig gemacht wird, wird auch das Erstellen des Zeitgebers rückgängig gemacht. Ähnliche Regeln gelten für das Aufheben eines Zeitgebers. Bereits gestartete Zeitgeber sind nach dem Beenden und dem Neustart eines Anwendungsservers weiter verfügbar.

Nicht persistente Zeitgeber

Mit EJB 3.1 wird der EJB-Zeitgeberservice erweitert, sodass jetzt neben persistenten Zeitgebern auch nicht persistente EJB-Zeitgeber verfügbar sind. Die Semantik und das Verhalten nicht persistenter Zeitgeber sind mit der Semantik und dem Verhalten persistenter Zeitgeber identisch. Nicht persistente Zeitgeber haben aber nicht den Systemaufwand für den Datenspeicher. Der Lebenszyklus eines nicht persistenten Zeitgebers unterscheidet sich von dem eines persistenten Zeitgebers. Während persistente Zeitgeber nach dem Beenden und dem Neustart eines Anwendungsservers weiter verfügbar sind, sind nicht persistente Zeitgeber nur aktiv, solange der Anwendungsserver aktiv ist. Im Gegensatz zu persistenten Zeitgebern gibt es bei nicht persistenten Zeitgebern keine Befehle zum Suchen oder Aufheben der Zeitgeber. Nicht persistente Zeitgeber werden aufgehoben, wenn der Anwendungsserver gestoppt wird oder den aktiven Status verlässt.

Die Erstellung und Aufhebung nicht persistenter Zeitgeber ist wie bei den persistenten Zeitgebern transaktionsorientiert. Wenn ein Zeitgeber in einer Transaktion erstellt wird und diese Transaktion später rückgängig gemacht wird, wird auch das Erstellen des Zeitgebers rückgängig gemacht. Ähnliche Regeln gelten für das Aufheben eines Zeitgebers.

Sie können nicht persistente Zeitgeber so konfigurieren, dass sie einen Threadpool gemeinsam mit persistenten Zeitgebern nutzen oder einen eigenen Threadpool haben, der nicht gemeinsam mit persistenten Zeitgebern genutzt wird.

Programmgesteuert erstellte Zeitgeber

Ein programmgesteuert erstellter persistenter Zeitgeber ist nach dem Beenden und dem Neustart eines Anwendungsservers weiter verfügbar, sofern er nicht aufgehoben wurde. Der Administrator des Anwendungscodes oder der Systemadministrator ist dafür verantwortlich, einen programmgesteuert erstellten Zeitgeber, der nicht mehr benötigt wird, zu löschen.

Wenn programmgesteuert ein Zeitgeber erstellt werden soll, der Ihrer Enterprise-Bean zugeordnet ist, ruft die Bean die Methode getTimerService() für die anwendbare Kontextinstanz auf, um einen Verweis auf das TimerService-Objekt zu erhalten. Außerdem ruft die Bean eine der Methoden des Zeitgeberservice auf, z. B. createTimer, um den Zeitgeber für die Bean anzugeben. Diese Zeitgeberinstanz wird nun Ihrer Bean zugeordnet. Die Methoden des Zeitgeberservice sind in der Spezifikation EJB 3.1 beschrieben. Sie können die Zeitgeberinstanz jetzt als lokales Objekt an anderen Java-Code übergeben. Nachdem der Java™-Code die Zeitgeberinstanz empfangen hat, kann der Code alle von der Schnittstelle "javax.ejb.Timer" definierten Methoden verwenden, z. B. cancel() oder getTimeRemaining().

In einer Clusterumgebung kann ein programmgesteuert erstellter persistenter Zeitgeber in jedem beliebigen Cluster-Member ausgeführt werden. Ein programmgesteuert erstellter nicht persistenter Zeitgeber kann dagegen nur in der JVM ausgeführt werden, in der er erstellt wurde.

Automatisch erstellte Zeitgeber
Mit der Spezifikation EJB 3.1 wird der EJB-Zeitgeberservice erweitert. Ein Zeitgeber kann jetzt automatisch beim Start Ihrer Anwendung gestartet werden, ohne dass eine Bean aufgerufen werden muss, um programmgesteuert eine der Zeitgebererstellungsmethoden des Zeitgeberservice zu starten. Verwenden Sie für die automatische Erstellung von Zeitgebern die Annotation @Schedule oder das Element timeout-method des Implementierungsdeskriptors. Automatisch erstellte Zeitgeber werden vom Container als Resultat einer Anwendungsimplementierung erstellt.
Fehler vermeiden Fehler vermeiden: Der Befehl CancelEJBTimers hebt auch automatisch erstellte Zeitgeber auf. Wenn automatisch erstellte Zeitgeber aufgehoben werden, können sie nur durch Deinstallation und erneute Installation der Anwendung neu erstellt werden. gotcha
Zeitgeber in einer Clusterumgebung

In einer Clusterumgebung wird ein persistenter Zeitgeber nur in einem Cluster-Member ausgeführt. Dabei muss es sich nicht um den Cluster-Member handeln, in dem der Zeitgeber erstellt wurde. Ein nicht persistenter Zeitgeber kann in jedem Cluster-Member ausgeführt werden, in dem er erstellt wurde. Automatische nicht persistente Zeitgeber werden in jedem Cluster-Member ausgeführt, der die EJB enthält.

Automatische persistente Zeitgeber werden aus dem persistenten Speicher entfernt, wenn das zugehörige Modul bzw. die zugehörige Anwendung deinstalliert wird. Aktualisieren Sie daher Anwendungen, die automatische persistente Zeitgeber verwenden, nicht mit dem Feature "Rollout der Aktualisierung durchführen", denn damit würde die Anwendung deinstalliert und erneut installiert werden, während der Cluster aktiv ist. Dies kann in folgenden Fällen zu Fehlschlägen führen:

  • Wenn ein Zeitgeber in einem anderen Cluster-Member aktiviert wird, nachdem der Datenbankeintrag entfernt wurde und bevor der neue Datenbankeintrag erstellt wird, fällt der Zeitgeber aus. In einem solchen Fall wird in das FFDC-Protokoll (für die Erfassung von Fehlerdaten beim ersten Auftreten) eine Ausnahme com.ibm.websphere.scheduler.TaskPending geschrieben sowie die Nachricht SCHD0057W, die angibt, dass die Task-Informationen in der Datenbank geändert oder aufgehoben wurden.
  • Wenn ein Zeitgeber in einem Cluster-Member aktiviert wird, der seit Aktualisierung der Zeitgeberdaten in der Datenbank nicht aktualisiert wurde, kann der Zeitgeber ausfallen oder andere Fehler auslösen, falls die neuen Zeitgeberinformationen nicht mit dem alten Anwendungscode, der noch in dem Cluster-Member ausgeführt wird, kompatibel sind.

Wenn Sie mit dem Proxy-Server des Produkts arbeiten, definieren Sie auf Zellenebene keinen Scheduler, der für den EJB-Zeitgeberservice verwendet werden soll, da dies die Ausführung persistenter Zeitgeber verhindern würde, wenn der Proxy-Server die Scheduler-Zugangsberechtigung erhält. Da im Proxy-Server keine Anwendungen ausgeführt werden, gibt es keinen Anwendungscode, der die vom Scheduler gesendeten Zeitgeberereignisse handhaben könnte.

Wiederholung und Auslassung von Timeouts

Wenn Sie EJB-Zeitgeber verwenden, müssen Sie das Konzept des Ausfalls, der Wiederholung und des Auslassens von Timeouts verstehen.

  • Ein Ausfall bedeutet, dass die Ausführung eines Timeouts ohne Erfolg versucht wurde.
  • Eine Wiederholung ist ein weiterer Versuch, ein Timeout auszuführen, nachdem zuvor ein entsprechender Versuch fehlgeschlagen ist.
  • Eine Auslassung eines Timeouts bedeutet, dass die Ausführung eines Timeouts hätte versucht werden müssen, dieser Versuch jedoch unterlassen wurde, weil der Server nicht verfügbar oder damit ausgelastet war, die Ausführung eines zuvor ausgelassenen Timeouts zu wiederholen.
Das Wiederholungsverhalten spiegelt Folgendes wider:
  • Häufigkeit der fehlgeschlagenen Versuche des Servers, die ausgefallenen Timeouts auszuführen
  • Intervall zwischen den Wiederholungen des Servers
Das Verhalten ausgelassener Timeouts spiegelt Folgendes wider:
  • Aussage, ob der Server versucht hat, ausgelassene Timeouts auszuführen oder nicht
  • Zeitpunkt der ggf. versuchten Ausführung ausgelassener Timeouts
  • Intervall zwischen den versuchten Ausführungen ausgelassener Timeouts
Tabelle 1. Wiederholungs- und Auslassungsverhalten von Timeouts. Das Wiederholungs- und Auslassungsverhalten kann bei persistenten und nicht persistenten Zeitgebern auftreten.
Merkmal Standardverhalten Konfigurierbar
Anzahl der Wiederholungsversuche Für den Erfolg notwendige Anzahl

Persistente Zeitgeber werden vorübergehend inaktiviert, wenn der für die im Scheduler festgelegte Fehlerschwellenwert in einem Server erreicht ist. Weitere Informationen finden Sie im Artikel zum Stoppen fehlerhafter Tasks.

Ja (für nicht persistente Zeitgeber)
Intervall zwischen den Wiederholungsversuchen Der erste Wiederholungsversuch erfolgt unmittelbar.

Alle weiteren Wiederholungsversuche erfolgen bei persistenten Zeitgebern in dem für den Scheduler konfigurierten Abfrageintervall und bei nicht persistenten Zeitgebern im konfigurierten Wiederholungsintervall.

Ja
Nachholen ausgelassener Timeouts Alle ausgelassenen Timeouts werden nachgeholt. Nein
Zeitpunkt der Nachholung ausgelassener Timeouts Ausgelassene Timeouts werden von persistenten und nicht persistenten Zeitgebern nachgeholt, wenn die blockierenden Wiederholungsversuche gestoppt werden. Persistente Zeitgeber holen Timeouts außerdem nach, wenn ein nicht verfügbarer Server neu gestartet wird. Nein
Nächstes Timeout nach erfolgreichem Wiederholungsversuch und Nachholung ausgelassener Timeouts Nächster ursprünglich geplanter Zeitpunkt Nein

Die konfigurierbaren Merkmale werden für persistente Zeitgeber in der Schedulerinstanz konfiguriert und für nicht persistente Zeitgeber in der Zeitgeberkonfiguration.

Die folgenden Szenarios veranschaulichen, wie das Wiederholungs- und Auslassungsverhalten die Timeouts bei persistenten und nicht persistenten Zeitgebern beeinflusst.

Szenario für persistente Zeitgeber:

Ein persistenter Zeitgeber wird erstellt. Die erste Ausführung des Zeitgebers wird für 10.00 Uhr konfiguriert. Anschließend wird der Zeitgeber stündlich ausgeführt. Der den Zeitgeber unterstützende Scheduler ist mit einem Abfrageintervall von 30 Sekunden konfiguriert.

Der Zeitgeber soll um 10.00 Uhr ausgeführt werden, fällt jedoch aus, weil eine Datenbank nicht verfügbar ist. Die erneute Ausführung des Zeitgebers wird sofort und dann alle 30 Sekunden wiederholt, wenn der Scheduler abgefragt wird. Dennoch fällt der Zeitgeber bis 12.30 Uhr aus. Unmittelbar danach ist die Datenbank wieder online, sodass der nächste Wiederholungsversuch Erfolg hat. Der Server beendet die Wiederholung der bisher fehlgeschlagenen Versuche.

Jetzt beginnt der Server, die ausgelassenen Timeouts abzuarbeiten. Zuerst wird versucht, das Timeout auszuführen, das um 11.00 Uhr ausgeführt werden sollte. Dies gelingt um 12.31 Uhr. Wird der Scheduler 30 Sekunden später erneut abgefragt, versucht der Server das Timeout auszuführen, das um 12.00 Uhr ausgeführt werden sollte. Dies gelingt um 12.32 Uhr. Jetzt ist der Server auf dem aktuellen Stand. Das nächste Timeout wird zum ursprünglich geplanten Zeitpunkt ausgeführt, nämlich um 13.00 Uhr, und nicht eine Stunde nach dem letzten erfolgreichen Versuch, was um 13.32 Uhr gewesen wäre. Ab jetzt wird der ursprüngliche Zeitplan eingehalten. Der Zeitplan wird nicht ausgehend vom letzten erfolgreichen Timeout aktualisiert.

Szenario für nicht persistente Zeitgeber:

Ein nicht persistenter Zeitgeber wird erstellt. Die erste Ausführung des Zeitgebers wird für 10.00 Uhr konfiguriert. Anschließend wird der Zeitgeber stündlich ausgeführt. Dieser nicht persistente Zeitgeber ist mit fünf Wiederholungen und einem Wiederholungsintervall von 30 Minuten konfiguriert.

Der Zeitgeber soll um 10.00 Uhr ausgeführt werden, fällt jedoch aus, weil eine Datenbank nicht verfügbar ist. Die erneute Ausführung des Zeitgebers wird sofort wiederholt und schlägt erneut fehl. Nach dieser sofortigen Wiederholung wartet der Server das konfigurierte Wiederholungsintervall von 30 Minuten bis zum nächsten Wiederholungsversuch. Die Wiederholungsversuche werden um 10.30 Uhr und 11.00 Uhr durchgeführt und schlagen beide fehl. Die vierte Wiederholung findet schließlich um 11.30 Uhr statt und hat Erfolg, weil die Datenbank wieder online ist.

Jetzt beginnt der Server, die ausgelassenen Timeouts abzuarbeiten. Das ursprünglich für 11.00 Uhr geplante Timeout wird sofort ausgeführt und gelingt um 11.31 Uhr. Jetzt ist der Server auf dem aktuellen Stand. Das nächste Timeout wird zum ursprünglich geplanten Zeitpunkt ausgeführt, nämlich um 12.00 Uhr (und nicht eine Stunde nach dem letzten erfolgreichen Versuch, was um 12.32 Uhr gewesen wäre).

Verhalten der Methoden getNextTimeout und getTimeRemaining

Die Methode Timer.getNextTimeout gibt für persistente und nicht persistente Zeitgeber ein Objekt java.util.Date zurück, das angibt, für welchen Zeitpunkt die nächste Ausführung des Zeitgebers geplant ist. Wenn Sie die Methode getNextTimeout von einer Timeout-Callback-Methode für einen intervall- oder kalenderbasierten Zeitgeber aus aufrufen, gibt die Methode den nächsten geplanten Zeitpunkt zurück. Für kalenderbasierte Zeitgeber ohne künftige Timeouts löst die Methode wie in der Spezifikation EJB 3.1 gefordert die Ausnahme NoMoreTimeoutsException aus. Wenn Sie die Methode getNextTimeout von einer Timeout-Callback-Methode für einen Zeitgeber mit nur einer Aktion aus aufrufen, gibt die Methode den ursprünglich geplanten Zeitpunkt zurück. Wenn eine Timeout-Callback-Methode fehlschlägt und Wiederholungsversuche unternommen werden, gibt die Methode getNextTimeout den ursprünglich geplanten Zeitpunkt zurück, als hätten die fehlgeschlagenen Ausführungsversuche nicht stattgefunden. Die Methode Timer.getTimeRemaining gibt in allen Fällen die Differenz zwischen dem von getNextTimeout zurückgegebenen Wert und der aktuellen Systemzeit in Millisekunden zurück. Dies kann auch eine negative Zahl sein, wenn die geplante Ausführungszeit bereits vergangen ist.

Übernahmeverhalten bei automatisch erstellten Zeitgebern

Methoden automatischer Zeitgeber in einer Hierarchie von Bean-Klassen bewirken die Erstellung mehrerer Zeitgeber. Die Anzahl der einer Zeitgebermethode zugeordneten Zeitgeber hängt nicht davon ab, wie häufig die Methode im Quellcode vorkommt. Sie hängt vielmehr davon ab, wie viele Beans für diese Methode sichtbar sind. Beispiel:

@Stateless
public class Abean {

   @Schedule(hour=”1”)
   public void timerMethod1()


@Stateless
public class Bbean extends Abean {

   @Schedule(hour=”2”)
   public void timerMethod2()


@Stateless
public class Cbean extends Bbean {

   @Schedule(hour=”2”)
   public void timerMethod2()

In der obigen Bean-Klassenhierarchie werden drei automatische Zeitgeber mit der Callback-Methode Abean.timerMethod1 erstellt, einer für jede Instanz, die für diese Methode sichtbar ist. Ein Zeitgeber mit der Callback-Methode Bbean.timerMethod2 wird erstellt. Da diese Methode von der Bean Cbean außer Kraft gesetzt wird, wird nur ein Zeitgeber mit der Callback-Methode Cbean.timerMethod2 erstellt.

Wenn die Bean Abean aus dem obigen Beispiel vom Container verarbeitet wird, wird ein einzelner automatischer Zeitgeber mit der Callback-Methode Abean.timerMethod1 erstellt.

Wenn die Bean Bbean vom Container verarbeitet wird, wird ein automatischer Zeitgeber mit der Callback-Methode Bbean.timerMethod2 und ein weiterer automatischer Zeitgeber mit der Callback-Methode Abean.timerMethod1 erstellt.

Wenn die Bean Cbean vom Container verarbeitet wird, wird ein automatischer Zeitgeber mit der Callback-Methode CBean.timerMethod2 und ein weiterer automatischer Zeitgeber mit der Callback-Methode Abean.timerMethod1 erstellt. Für Bbean.timerMethod2 wird kein Zeitgeber erstellt, wenn die Bean Cbean verarbeitet wird. Bbean.timerMethod2 ist in der Klassenhierarchie von Cbean nicht sichtbar, weil sie von der Methode Cbean.timerMethod2 außer Kraft gesetzt wird.

Angenommen, die Annotation @Stateless aus dem obigen Beispiel würde aus den Klassen Abean und Bbean entfernt. In dem Fall wäre die Klasse Cbean die einzige EJB. Es würden demnach nur die für Cbean sichtbaren automatischen Zeitgeber erstellt werden, einer mit der Callback-Methode Abean.timerMethod1 und einer mit der Callback-Methode Cbean.timerMethod2.

Obwohl Beans identischen Code in der Callback-Methode einer übernommenen Bean gemeinsam nutzen können, kann dies zu einem polymorphen Laufzeitverhalten führen. Beispiel:

public class Employee { 

   @Schedule(hour=”1”, dayOfMonth=”-1”, info = "payroll timer")
   public void getSalaryIncrease() {
      printChecks(salary * rate());
   }

   protected float rate() {
      return (float)1.01;
   }

}

public class Manager extends Employee {

   protected float rate() {
      return (float)1.15;
   }

}

public class Executive extends Manager {

   protected float rate() {
      return (float)1.30;
   }

}

Im obigen Beispiel hat jede Bean-Instanz einen automatischen Zeitgeber mit der Callback-Methode getSalaryIncrease(). Obwohl alle Zeitgeber denselben Callback-Code gemeinsam nutzen, verwendet jede Bean durch die Polymorphie einen anderen Faktor für die Berechnung der Lohnerhöhung. Callback-Methoden von Zeitgebern können also genau jede Java-Methode polymorph sein.

Vorgehensweise

Ergebnisse

Sie haben einen persistenten oder nicht persistenten EJB-Zeitgeber programmgesteuert oder automatisch erstellt.


Symbol, das den Typ des Artikels anzeigt. Taskartikel



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