Warum sollte ich Spring Batch Jobrepository verwenden?

Question

Ich verstehe JobRepository wird für CRUD-Operationen des Job-Status verwendet. Ich verwende eine persistente Datenbank, speichert das JobRepository die historischen Metadaten in der Datenbank oder speichert es nur den laufenden Prozess?

Auch wenn ich eine Reihe von Jobs vom Job Scheduler ausgeführt habe und jeder von ihnen eine eigene JobRepository Datenbank hat, würden sie dieselben persistenten Tabellen teilen oder ich müsste für jedes JobRepository eine andere Datenbank erstellen?

Answer 1

Spring Batch JobRepository speichert Details zu jedem Batch-Job, nicht nur den aktuellen Job. Es spielt keine Rolle, wie oder wer den Job ausführt, solange die Jobs die gleiche jobRepository-Konfiguration in Ihrem Spring-Kontext verwenden. Die Jobdetails werden in derselben Datenbank gespeichert, die für das JobRepository konfiguriert ist.

<bean id="jobRepository" 
     class="org.springframework.batch.core.repository.support.JobRepositoryFactoryBean"> 
     <property name="dataSource" ref="dataSourceName" /> 
</bean> 

Answer 2

Der Job-Repository erforderlich Frühjahr Batch laufen, aber es ist eines dieser Dinge, die ein wenig Arbeit erfordert, um tatsächlich einen beliebigen Wert zu liefern (z Frühjahr Batch-Server-Betreiber der Einrichtung oder Ihre eigenen ui zu schreiben). In der Praxis in den meisten Projekten, die ich gesehen habe, die Spring Batch verwenden, ist das Job-Repository eine rein schreibende Sache, die dazu neigt, vollständig ignoriert zu werden. Du musst es haben, niemand sieht es jemals an. In Tabellen mit einem SQL-Client zu suchen, um Protokolle mit Fehlern, Warnungen und Stack-Traces zu finden, ist keine Sache, wenn Sie die Protokollierung richtig einrichten und ordnungsgemäß protokollieren eine harte Anforderung für seriöse serverseitige Unternehmen sind.

IMHO, das Job-Repository optional zu machen wäre eine gute Sache, da es eine Menge Komplexität hinzufügt. Die meisten Projekte brauchen es einfach nicht. Und die meisten Projekte, die dies benötigen (z. B. Multi-Node-Batch-Cluster) sollten sich wahrscheinlich auch andere Technologien ansehen, die eigentlich eine Cluster-übergreifende Zustandsverwaltung bereitstellen sollen (z. B. Zookeeper). An diesem Punkt sind Sie wahrscheinlich besser dran an Dingen wie Spring Cloud, Hadoop oder ähnlichen Lösungen. Spring Batch Art ist ein Sprungbrett für diese Art von Lösungen.

einige Dinge sein off bewusst:

• Spring Batch erstellen und füllen Tabellen mit Informationen, die Sie wahrscheinlich als Produktionsdatenbank an einem anderen Ort wollen.
• Wenn Sie mit Spring-Batch-Tabellen in Ihrer Produktionsdatenbank enden (zB weil die Bereitstellung einer zusätzlichen Datenbank für Tabellen, die Sie im Grunde nicht interessieren, zu viel wäre), sollten Sie sichergehen, dass diese Tabellen Teil davon sind Ihre Db-Migrationsskripte.
• Sie sollten auch in Betracht ziehen, die in diesen Tabellen gesammelten Daten regelmäßig zu bereinigen, besonders wenn Sie nie etwas damit machen.
• Standardmäßig können Jobs nur einmal ausgeführt werden. Sie müssen sie tatsächlich konfigurieren, damit sie mehrmals ausgeführt werden können. Es speichert in dem Job-Repository, das es bereits ausgeführt wurde, und standardmäßig wird nichts tun, wenn Sie etwas ein zweites Mal ausführen. Dieses "Feature" hat mich schon mehrfach überrascht. Die Lösung fügt Ihren Jobs einen .incrementer(new RunIdIncrementer()) hinzu.
• Spring Batch setzt voraus, dass Ihre Jobs und Schritte in einem Cluster verteilt werden (auch wenn dies für die meisten Projekte nie der Fall sein wird). Daher ist das Job-Repository effektiv die einzige Möglichkeit, Informationen weiterzugeben (über die Ausführungskontexte, die persistent bleiben).