2014-10-30 18 views
5

W usłudze documentation pakietu wiosennego do skonfigurowania kroku przezroczysty obraz opisuje, w jaki sposób odbywa się proces odczytu i zapisu.Wiosenna dokumentacja wsadowa dotycząca kroku zorientowanego na porcje a rzeczywistość?

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

odpowiednich (według dokumentu)

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); 

Jednakże gdy debugowania i umieścić przerwania w sposobie odczytu czytnika i przerwania w sposobie proces procesora widzę następujące zachowanie:

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

Czy dokumentacja jest nieprawidłowa? Czy też brakuje mi jakiejś konfiguracji, aby zachowywać się jak dokumentacja (niczego tam nie znalazłem).

Problem polega na tym, że każdy kolejny odczytany teraz zależy od statusu z procesora. Czytnik jest kompozytem, ​​który odczytuje dwa źródła równolegle, w zależności od odczytanych elementów w jednym ze źródeł tylko pierwsze, drugie lub oba źródła są odczytywane podczas jednej operacji odczytu. Ale stan, z którego źródła są czytane, dokonywany jest w procesorze. Obecnie jedynym rozwiązaniem jest przejście do commit-interval 1, które nie jest zbyt optymalne pod względem wydajności.

+0

można go wypróbować za pomocą niestandardowego czytnika, który otacza standardowy czytnik i niestandardową logikę. –

+0

Tak, pomyślałem o tym, ale nie jest to zgodne z modelem partii. Czytelnik nie ponosi odpowiedzialności za tworzenie danych wyjściowych. – Juru

+0

Spróbowałbym z tabelami bazy danych dla źródeł (import z pierwszą partią) i odczytać dane z odpowiednim SQL (druga partia do przetwarzania biznesowego) –

Odpowiedz

3

Krótka odpowiedź brzmi, masz rację, nasza dokumentacja nie jest dokładna w modelu chunking. To coś, co należy zaktualizować. Istnieją powody, dla których tak właśnie jest (mają one głównie związek z tolerancją na błędy). Ale to nie rozwiązuje twojego problemu. Dla Państwa przypadku użycia, istnieje kilka możliwości:

  • Skonfiguruj swoją pracę za pomocą konfiguracji JSR-352 - model przetwarzania dla JSR-352 jest to, co mówi nasz dokumentacja (wzięli go jako ewangelii zamiast tego, co wiosennym Batch naprawdę robi). Ponieważ Spring Batch obsługuje JSR-352, po prostu zmieniając konfigurację i sposób uruchamiania zadań, uzyskasz takie same wyniki. Istnieją ograniczenia JSR-352, które nie wchodzą w zakres tej dyskusji, ale jest to jedna z opcji.
  • Inną opcją jest robienie tego, co sugeruje Michael Pralow. Chociaż rozumiem twoje obawy dotyczące rozdzielania obaw, brzmi to tak, jakbyś już łamał tę regułę, biorąc pod uwagę, że twój procesor generuje dane wyjściowe, które czytelnik potrzebuje (lub jesteś dzielenie tego stanu w jakiś inny sposób?).
  • Inne opcje - nie wiedząc więcej o swojej pracy, mogą istnieć inne sposoby na uporządkowanie swojej pracy, która działa dobrze (takie jak przenoszenie logiki na wiele etapów itd.), A mimo to można uzyskać oddzielenie problemów, które Spring Batch stara się dopuszczać ale potrzebuję więcej twojej konfiguracji, aby móc w tym pomóc.
+0

Dla opcji drugiej. Tak, istnieje stan wewnątrz kontekstu wykonania kroku. Nie używa się wyjścia procesora. – Juru

+0

Jak mogę udostępnić ci moją konfigurację zadania? To nie jest tak naprawdę związane z tym problemem. – Juru

+0

Utwórz nowy temat, w którym zapyta, jak rozwiązać problem zarządzania stanem między procesorem a czytnikiem w pakiecie Spring Batch. –

Powiązane problemy