Spring-Batch-Dokumentation über Chunk-orientierten Schritt gegen die Realität?

Question

Auf der documentation von Spring Batch zum Konfigurieren eines Schritts beschreibt ein klares Bild, wie der Lesevorgang und das Schreiben durchgeführt wird.

read 
process 
... 
read 
process 
// until #amountOfReadsAndProcesses = commit interval 
write 

entsprechenden (entsprechend dem DOC):

List items = new Arraylist(); 
for(int i = 0; i < commitInterval; i++){ 
    Object item = itemReader.read() 
    Object processedItem = itemProcessor.process(item); 
    items.add(processedItem); 
} 
itemWriter.write(items); 

Jedoch, wenn ich Debug- und einen Haltepunkt in dem Leseverfahren des Lesers gelegt und ein Unterbrechungspunkt in dem Prozeßverfahren des Prozessors I der SOE folgendes Verhalten:

read 
... 
read 
// until #amountOfReads = commit interval 
process 
... 
process 
// until #amountOfProcesses = commit interval 
write 

So ist die Dokumentation falsch? Oder fehlt mir eine Konfiguration, damit sie sich wie die Dokumentation verhält (habe dort nichts gefunden).

Das Problem, das ich habe, ist, dass jedes aufeinanderfolgende Lesen jetzt von einem Status vom Prozessor abhängt. Der Leser ist ein Verbund, der zwei Quellen parallel liest, abhängig von den gelesenen Elementen in einer der Quellen werden nur die erste, zweite oder beide Quellen während einer Leseoperation gelesen. Der Status der zu lesenden Quellen wird jedoch im Prozessor festgelegt. Gegenwärtig ist die einzige Lösung das Commit-Intervall 1, das für die Performance nicht optimal ist.

Answer 1

Die kurze Antwort ist, Sie haben Recht, unsere Dokumentation ist nicht korrekt auf dem Chunking-Modell. Es ist etwas, das aktualisiert werden muss. Es gibt Gründe dafür, warum es so ist (sie haben hauptsächlich damit zu tun, wie Fehlertoleranz gehandhabt wird). Aber das geht nicht auf Ihr Problem ein. Für Ihren Anwendungsfall gibt es ein paar Optionen:

• Ihre Aufgabe Konfigurieren Sie die JSR-352-Konfiguration mit - Das Verarbeitungsmodell für JSR-352 ist das, was unsere Dokumentation sagt (sie nahm es als Evangelium statt, was Spring Batch tut wirklich). Da Spring Batch JSR-352 unterstützt und nur Ihre Konfiguration und das Starten Ihrer Jobs ändert, erzielen Sie dieselben Ergebnisse. Es gibt Einschränkungen von JSR-352, die für diese Diskussion nicht in Betracht kommen, aber es ist eine Option.
• Eine andere Möglichkeit wäre, das zu tun, was Michael Pralow vorschlägt - Während ich Ihre Bedenken bezüglich der Trennung von Bedenken verstehe, klingt es, als würden Sie diese Regel bereits brechen, da Ihr Prozessor eine Ausgabe erzeugt, die der Leser benötigt (oder Sie sind) diesen Zustand auf andere Weise teilen?).
• Andere Optionen - Ohne mehr über Ihren Job zu wissen, gibt es möglicherweise andere Möglichkeiten, Ihren Job zu strukturieren (z. B. Verschieben von Logik in mehrere Schritte usw.) und immer noch die Trennung von Problemen, die Spring Batch zu berücksichtigen versucht aber ich müsste mehr von deiner Konfiguration sehen, um dort helfen zu können.