Java-Stapelpersistenz konfigurieren

Die Java™-Stapelfunktion (Java Batch) verwendet einen persistenten Speicher, damit der Status, die Prüfpunkte und die persistenten Anwendungsdaten während mehrerer Ausführungen einer Jobinstanz erhalten bleiben. Der persistente Speicher ermöglicht es, dass eine Jobinstanz erneut gestartet werden kann, wenn eine frühere Ausführung fehlschlägt oder gestoppt werden muss, indem er den erneut gestarteten Job mit den erforderlichen Daten bereitstellt.

Konfiguration der speicherbasierten Java-Stapelpersistenz

Die Stapelpersistenz ermöglicht es, dass eine Jobinstanz erneut gestartet werden kann, wenn die Ausführung mit dem Status FAILED (Fehlgeschlagen) oder STOPPED (Gestoppt) beendet wird. Bei Fehlen einer Datenbankkonfiguration für Stapelpersistenz verwendet Java-Stapel standardmäßig speicherbasierte Persistenz zur Verfolgung des Status, der Prüfpunkte und der persistenten Anwendungsdaten während mehrerer Ausführungen einer Jobinstanz.

Anmerkung: Die speicherbasierte Standardpersistenz wird mit einer offensichtlichen, aber signifikanten Einschränkung bereitgestellt. Wenn die Laufzeitumgebung des Stapelcontainers oder die Server-JVM ausfällt oder erneut gestartet wird, geht die Persistenz verloren. Diese Funktion ist nur für Entwicklungszwecke vorgesehen und darf nicht für Produktionssysteme oder kritische Stapelverarbeitungsunterstützung in Betracht gezogen werden.

Konfiguration der datenbankbasierten Java-Stapelpersistenz

Die Stapelpersistenz kann über einen Datenbankspeicher konfiguriert werden. Der Datenbankspeicher verweist auf eine Datenquelle, die wiederum auf einen JDBC-Treiber, eine bestimmte Datenbankposition und weitere angepasste Datenbankeigenschaften verweist. Die qualifizierten Namen der Stapelpersistenztabellen können mit den Attributen schema und tablePrefix des Datenbankspeichers konfiguriert werden.

Ein Standarddatenbankspeicher mit dem Namen "defaultDatabaseStore" wird bereitgestellt und durch Konfigurieren der Standarddatenquelle mit dem Namen "DefaultDataSource" aktiviert.

Alternativ können Sie einen anderen Datenbankspeicher konfigurieren, indem Sie ein Element databaseStore verwenden und Stapelpersistenz konfigurieren, indem Sie ein

batchPersistence-Element mit einem jobStoreRef-Attribut hinzufügen, das Ihr databaseStore-Element referenziert.

Überlegungen zum Datenbankverbindungspooling von Java-Stapel

Im Allgemeinen folgt die Java-Stapellaufzeit einem Muster des Typs "abrufen, verwenden, schließen", wenn ein Aufruf an die Datenbank erfolgt und hält in der Regel JDBC-Verbindungen auch nur so lange aufrecht, wie es sie verwendet. Das bedeutet, dass die Frage, wie viele Verbindungen für die Ausführung einer bestimmten Anzahl von Jobs und Partitionen auf einem Server erforderlich sind, fast ausschließlich vom Administrator beantwortet werden muss.

Es ist nicht erforderlich, die Größe des Verbindungspools auf einen Wert größer-gleich der Anzahl aktiver Jobs und Partitionen setzen, um Deadlocks zu vermeiden. Ressourcenkonflikte aufgrund einer zu geringen Anzahl von Verbindungen können u. U. immer noch zu suboptimaler Leistung führen. Es wird auch immer noch eine Mindestanzahl von Verbindungen erforderlich sein, wahrscheinlich größer als 1, um bestimmte Pfade, wie z. B. die Aktivierung von Stapelkomponenten, auszuführen. Administratoren können mit den Standardwerten beginnen und mithilfe von Verbindungspoolmetriken und dem Überwachen des Verbindungspools beispielsweise die Ressourcenauslastung und die Leistung ausgleichen. Dies gilt für die Laufzeitnutzung von JDBC-Verbindungen. Administratoren müssen möglicherweise immer noch JDBC-Verbindungspooling in Betracht ziehen, da es von Anwendungscode verwendet wird.

Automatische und manuelle Erstellung von Datenbanktabellen

Standardmäßig erstellt die Stapelverarbeitungslaufzeit automatisch nicht vorhandene Tabellen im Stapelpersistenzdatenbankspeicher. Dieses automatische Erstellungsverhalten erweitert außerdem vorhandene Tabellen und die Erstellung neuer Spalten in den Fällen, in denen diese neuen Spaltendefinitionen in Wartungsfenstern angewendet wurden.

Alternativ dazu kann eine auf der Serverkonfiguration basierende DLL mit dem Script ddlGen generiert werden. Falls erforderlich, kann die DLL angepasst werden, bevor die Tabellen manuell erstellt werden. Diese DDL umfasst auch die Serverkonfiguration, wie z. B. schema und tablePrefix, und sie enthält außerdem die entsprechende SQL fü r den Datenbanktyp der vom Datenbankspeicher referenzierten Datenquelle.

Anmerkung: Die angepasste DDL muss Primärschlüssel-IDs mit positiven ganzen Zahlen verwenden. Als Einschränkung der Datenbankpersistenz akzeptiert die Java-Stapelfunktion keine negativen IDs oder IDs ohne ganze Zahl, die persistent in den ID-Spalten für den Primärschlüssel gespeichert sind. Die Java-Stapelcontainerlaufzeit führt nur Jobs aus, die Job-IDs mit positiven ganzen Zahlen verwenden, die persistent in den ID-Spalten für den Primärschlüssel gespeichert sind.

Die automatische Erstellung von Tabellen kann mit dem Attribut createTables="false" im Datenbankspeicher (databaseStore) inaktiviert werden. Mit dieser Option kann auch sichergestellt werden, dass manuell erstellte Tabellen anstelle der automatisch erstellten Tabellen verwendet werden, wenn die Stapellaufzeit die manuell erstellten Tabellen unerwarteterweise nicht findet.

Informationen darüber, wie Sie Tabellen durch Anpassen der generierten DDL, einschließlich möglicher weiterer Anpassungen, erstellen, finden Sie im Whitepaper Liberty Batch - Job Repository Configuration. Obwohl dieses Whitepaper für DB2 unter z/OS-Be triebssystemen gedacht ist, können die Informationen hilfreich für andere Datenbanken und Plattformen sein.

Beispiele für Persistenzkonfiguration

Standarddatenbankspeicher mit automatisch erstellten Tabellen, die mit der Derby-Datenbank RUNTIMEDB konfiguriert wurden:

<!-- Derby-JDBC-Treiber -->
<library id="DerbyLib"> 
    <fileset dir="${server.config.dir}/resources/derby" /> 
</library> 
<!-- Datenquelle für Stapeltabellen und möglicherweise weitere Komponenten. --> 
<dataSource id="DefaultDataSource"> 
    <jdbcDriver libraryRef="DerbyLib" /> 
    <properties.derby.embedded
        databaseName="${server.config.dir}/resources/RUNTIMEDB"
        createDatabase="create"
        user="user" password="pass" /> 
</dataSource>

Stapelspezifischer Datenbankspeicher mit manuell erstellten Tabellen, angepasstem Schema, Tabellenpräfix und Stapeldatenquelle

<batchPersistence jobStoreRef="BatchDatabaseStore"/>

<!-- Datenbankspeicherkonfiguration, die nur von Stapelkomponenten verwendet wird. -->
<databaseStore id="BatchDatabaseStore" dataSourceRef="BatchDS"
    createTables="false" schema="HLQ" tablePrefix="JB1"/> 

<!-- Datenquelle für Stapeltabellen -->
<dataSource id="BatchDS"> 
    <jdbcDriver libraryRef="DerbyLib" /> 
     ...
</dataSource>

Standarddatenbankspeicher mit Authentifizierungskonfiguration, angepasstem Scheman, automatisch erstellten Tabellen, Standarddatenquelle:

<!-- Datenbankspeicher, der von Stapel- und möglicherweise weiteren Laufzeitkomponenten verwendet wird. --> 
<databaseStore id="defaultDatabaseStore" schema="HLQ">
    <authData user="user1" password="password1"/>  
</databaseStore>

<!-- Datenquelle für Stapeltabellen und möglicherweise weitere Komponenten. --> <dataSource id="DefaultDataSource"> 
    <jdbcDriver libraryRef="DerbyLib" /> 
    ...
</dataSource>

Referenz

Im Whitepaper unter https://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102716 finden Sie eine Beschreibung zum manuellen Erstellen von Tabellen durch Anpassen der generierten DDL, einschließlich möglicher weiterer Anpassungen.


Symbol das den Typ des Artikels anzeigt. Referenzartikel

Dateiname: rwlp_batch_persistence_config.html