Massenverarbeitung mit Restart, Skip und Retry

Transaktionen in Spring Batch

Tobias Flohre


Gleich eine Sache vorweg: Dieser Artikel ist nichts für Einsteiger. Wir gehen in medias res und schauen dem Framework unter die Haube. Da die Domänensprache von Spring Batch glücklicherweise sehr intuitiv ist, sollten aber auch Leser, die bisher nichts oder wenig mit Spring Batch gemacht haben, einen Großteil des Artikels verstehen können. Eine Einführung in Spring Batch und Beispiele bieten [1], [2], [3].

Jedem Entwickler ist die Wichtigkeit von Trans­aktionen bewusst. Und doch muss man sich meistens nicht tiefergehend mit ihnen beschäftigen, denn es genügt eine @Transactional- Annotation oder das Wissen, dass die EJB das schon regelt, um ruhigen Gewissens den Businesscode zu implementieren. In Batch-Anwendungen ist das anders: Diese verarbeiten viele Daten am Stück, üblicherweise so viele, dass eine Verarbeitung innerhalb einer Transaktion nicht in Frage kommt. Es müssen also Commits her, die dann natürlich zur Folge haben, dass ein abgebrochener Job nicht komplett zurückgerollt werden kann. Das wirft Fragen auf: Können wir den Job einfach neu starten, oder verarbeiten wir dann bestimmte Daten doppelt? Welche Daten sind verarbeitet worden, welche nicht? Spring Batch bietet Möglichkeiten, einen Job Restart-fähig zu machen. Spring Batch kann auch fehlerhafte Elemente überspringen (Skip) oder erneut verarbeiten (Retry). Aber natürlich hat es in jedem Skip- und Retry-Fall vorher ein Rollback gegeben, und da üblicherweise nicht eine Transaktion pro Element gestartet wird, hat das Rollback auch gesunde Elemente umfasst. Wie löst Spring Batch diese Aufgabe? Diese und weitere Fragen sollen in diesem Artikel beantwortet werden. Los geht es nun aber mit dem grundsätzlichen Transaktionsmodell in Spring Batch.

Transaktionen in Chunk-orientierten Steps

Spring Batch liefert eine klare Domänensprache, die ­direkt im XML-Namespace umgesetzt ist (Listing 1).

Listing 1

Wir haben Jobs, die aus beliebig vielen Steps bestehen können. Ein Step kann entweder ein TaskletStep oder ein Chunk-orientierter Step sein, wobei TaskletSteps eher für die Anbindung von Legacy-Code geeignet sind. Chunks teilen sich weiter auf in Reader, Processors und Writer, und erst hier kann Spring Batch all seine Vorteile ausspielen. Deswegen werde ich mich in diesem Artikel auch auf die Chunk-orientierten Steps...

Massenverarbeitung mit Restart, Skip und Retry

Transaktionen in Spring Batch

Tobias Flohre


Gleich eine Sache vorweg: Dieser Artikel ist nichts für Einsteiger. Wir gehen in medias res und schauen dem Framework unter die Haube. Da die Domänensprache von Spring Batch glücklicherweise sehr intuitiv ist, sollten aber auch Leser, die bisher nichts oder wenig mit Spring Batch gemacht haben, einen Großteil des Artikels verstehen können. Eine Einführung in Spring Batch und Beispiele bieten [1], [2], [3].

Jedem Entwickler ist die Wichtigkeit von Trans­aktionen bewusst. Und doch muss man sich meistens nicht tiefergehend mit ihnen beschäftigen, denn es genügt eine @Transactional- Annotation oder das Wissen, dass die EJB das schon regelt, um ruhigen Gewissens den Businesscode zu implementieren. In Batch-Anwendungen ist das anders: Diese verarbeiten viele Daten am Stück, üblicherweise so viele, dass eine Verarbeitung innerhalb einer Transaktion nicht in Frage kommt. Es müssen also Commits her, die dann natürlich zur Folge haben, dass ein abgebrochener Job nicht komplett zurückgerollt werden kann. Das wirft Fragen auf: Können wir den Job einfach neu starten, oder verarbeiten wir dann bestimmte Daten doppelt? Welche Daten sind verarbeitet worden, welche nicht? Spring Batch bietet Möglichkeiten, einen Job Restart-fähig zu machen. Spring Batch kann auch fehlerhafte Elemente überspringen (Skip) oder erneut verarbeiten (Retry). Aber natürlich hat es in jedem Skip- und Retry-Fall vorher ein Rollback gegeben, und da üblicherweise nicht eine Transaktion pro Element gestartet wird, hat das Rollback auch gesunde Elemente umfasst. Wie löst Spring Batch diese Aufgabe? Diese und weitere Fragen sollen in diesem Artikel beantwortet werden. Los geht es nun aber mit dem grundsätzlichen Transaktionsmodell in Spring Batch.

Transaktionen in Chunk-orientierten Steps

Spring Batch liefert eine klare Domänensprache, die ­direkt im XML-Namespace umgesetzt ist (Listing 1).

Listing 1

Wir haben Jobs, die aus beliebig vielen Steps bestehen können. Ein Step kann entweder ein TaskletStep oder ein Chunk-orientierter Step sein, wobei TaskletSteps eher für die Anbindung von Legacy-Code geeignet sind. Chunks teilen sich weiter auf in Reader, Processors und Writer, und erst hier kann Spring Batch all seine Vorteile ausspielen. Deswegen werde ich mich in diesem Artikel auch auf die Chunk-orientierten Steps...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang