CommonJ TimerManager versus EJB3 TimerService

8

Ich muss einen einfachen (nicht geclusterten) Timer für WebLogic implementieren und es scheint, dass es zwei verschiedene "Standard" -Optionen gibt

  • Timer und Work Manager API (CommonJ)
  • EJB3.0 TimerService

Hat jemand Tipps zur Verwendung des CommonJ TimerManager im Vergleich zur Verwendung des EJB3 TimerService in WebLogic 10.0?

Danke.

    
fglez 07.07.2011, 07:12
quelle

3 Antworten

3

TimerService in EJB 3.0 ist im Vergleich zum CommonJ Timer Manager etwas eingeschränkt. Zum Beispiel erfordert es einen Standardcode und eine containerspezifische Konfiguration, um eine flexible Aufgabenplanung zu implementieren. Dies wurde mit der Einführung von @Scheduled Annotation in EJB 3.1 vereinfacht.

Wenn Sie bei EJB 3.0 bleiben und eine einfach und flexibel konfigurierbare Aufgabenplanung benötigen, ist die CommonJ Timer Manager API eine praktikable Option.

Darüber hinaus kann der Taskplaner von Spring Framework (org.springframework.scheduling.TaskScheduler) die Timer Manager-API abstrahieren und eine deklarative Konfiguration mithilfe von Cron-Ausdrücken ermöglichen.

    
fnt 09.01.2012, 16:29
quelle
8

CommonJ wurde ursprünglich unter JSR 237 vorgeschlagen, das 2008 zurückgezogen und in JSR 236 Concurrency Utilities für die Java EE-Plattform integriert wurde. Beachten Sie, dass dies eine wesentliche Änderung gegenüber dem von CommonJ vorgeschlagenen Standard und API bedeutet. Der Name CommonJ wird entfernt, die neuen Pakete befinden sich unter javax.enterprise.concurrent statt commonj.timers und commonj.work, und die ursprünglichen Klassen TimerManager, Timer und TimerListener werden durch nicht entsprechende Schnittstellen / Klassen ersetzt, einschließlich ManagedScheduledExecutorService, ManagedTask, ManagedTaskListener, Trigger.

Der letztgenannte JSR 236 wurde vor kurzem in die Öffentlichkeit gebracht und sollte daher bald zu einem Standard werden. Ab November 2012 ist es ein vorläufiger Kandidat für die Aufnahme in die Java EE 7-Spezifikation (JSR 342), aber dies wird bestätigt, sobald 342 fertiggestellt und veröffentlicht ist.

Daher die folgenden Probleme mit CommonJ:

  • es ist nicht und wird kein Java-Standard sein, bis sich unter JSR 236, der enthalten sein wird, wesentlich geändert hat in Java EE 7 oder höher
  • es geht vermutlich über Ihre Anforderungen hinaus und ist es komplizierter als der EJB 3.0 Timer Service

Ich schlage vor, dass Sie den EJB 3.0 Timer Service verwenden, wenn er Ihren Anforderungen entspricht.

    
Glen Best 23.02.2013 02:47
quelle
0

Ja, wenn TimeService-Funktionen Ihre Anforderungen abdecken, verwenden Sie sie - sie sind Teil des Java EE-Standards! Warum sollte eine andere Bibliothek benutzt werden, wenn nicht unbedingt notwendig?

    
home 08.07.2011 11:29
quelle