Zum Hauptinhalt springen

Events, Scheduling, Async und Observability

Worauf die Prüfung abzielt​

Events im Prozess, zeitgesteuerte Jobs, asynchrone Ausführung, Diagnose in Produktion.

Das musst du können​

  • ApplicationEventPublisher veröffentlicht Events im Context.
  • @EventListener reagiert darauf.
  • Events sind standardmäßig synchron.
  • @TransactionalEventListener z. B. mit AFTER_COMMIT.
  • @Scheduled + @EnableScheduling für zeitbasierte Jobs.
  • fixedRate = Start-zu-Start. fixedDelay = Ende-zu-nächstem-Start.
  • @Async + @EnableAsync für andere Threads.
  • @Async ist proxy-basiert — Self-Invocation umgeht es.
  • Actuator: Health, Metrics, Mappings, Beans, Conditions, Scheduled Tasks.
  • Endpoints bewusst exponieren und absichern.

Passende Buchkapitel​

Typische Prüfungsfallen​

Events sind kein Message Broker — in-process, nicht durable.

@Scheduled ist kein verteiltes Job-System. Jede Instanz kann denselben Job laufen lassen.

@Async teilt Transaction-, Request- oder Security-Context nicht automatisch.

Kurz selbst prüfen​

  • Synchrone Spring Events?
  • Was bedeutet AFTER_COMMIT?
  • fixedRate vs. fixedDelay?
  • Warum läuft derselbe Job auf jeder Instanz?
  • Welche Actuator-Endpoints besonders schützen?
Musterantworten

Synchron: Publisher wartet, bis Listener durch sind (ohne explizite Async-Konfiguration).

AFTER_COMMIT: Listener erst nach erfolgreichem Commit der umgebenden Transaktion.

fixedRate misst zwischen Starts. fixedDelay zwischen Ende und nächstem Start.

Jede App-Instanz hat eigenes @Scheduled — bei mehreren Pods brauchst du Locking, Idempotenz oder externen Scheduler.

Vorsichtig mit env, beans, configprops, mappings, conditions, loggers, teils metrics — nicht öffentlich exponieren.

Merksatz​

Events = etwas ist passiert. Scheduling = Zeit. Async = Threads. Actuator = Produktion sichtbar machen.