Configurazione della persistenza batch Java

Il batch Java™ può configurare un repository di lavori per utilizzare un archivio persistente per conservare lo stato, i punti di controllo e i dati persistenti dell'applicazione in più esecuzioni di un'istanza di lavoro. L'archivio persistente consente il riavvio di un'istanza di lavoro se un'esecuzione precedente non riesce o deve essere arrestata fornendo al lavoro riavviato i dati appropriati.

Repository lavori

Un repository di lavori include un archivio persistente supportato da un database o un archivio persistente basato su memoria destinato solo allo sviluppo. La funzione batch Liberty consente flessibilità nella definizione di un ambiente in cui più server possono utilizzare un archivio persistente comune o un repository di lavori. È importante comprendere che molte funzioni sono nell'ambito di tutti i server configurati per utilizzare lo stesso repository di lavori. Per ulteriori informazioni, consultare Repository lavori.

Configurazione della persistenza basata sulla memoria batch Java

La persistenza batch consente a un'istanza di lavoro di essere riavviata se l'esecuzione termina in uno stato NON RIUSCITO o ARRESTATO. In assenza della configurazione del database per la persistenza batch, per impostazione predefinita il batch Java utilizza la persistenza basata sulla memorizzazione per tenere traccia dello stato, dei punti di controllo e dei dati persistenti dell'applicazione su più esecuzioni di un'istanza di lavoro.

Nota: la persistenza predefinita basata sulla memoria viene fornita con una limitazione evidente ma significativa.  Se l'ambiente di runtime del contenitore batch o la JVM del server si arrestano o vengono riavviati, la persistenza viene persa. Questa funzione è solo per scopi di sviluppo e non deve essere considerata per i sistemi di produzione o per il supporto di elaborazione batch critico.

Configurazione della persistenza del database batch Java

La persistenza batch può essere configurata tramite un archivio database.  L'archivio database fa riferimento a un'origine dati, che a sua volta fa riferimento a un driver JDBC , a un'ubicazione database specifica e ad altre proprietà personalizzate del database.   I nomi completi delle tabelle di persistenza batch possono essere configurati utilizzando gli attributi schema e tablePrefix dell'archivio database stesso.

Viene fornito un archivio di database predefinito, denominato defaultDatabaseStore,, che viene attivato configurando l'origine dati predefinita, denominata DefaultDataSource.

Oppure è possibile configurare un archivio database differente utilizzando un elemento databaseStore e configurare la persistenza batch per utilizzarlo aggiungendo un

batchPersistence con un attributo jobStoreRef che fa riferimento a databaseStore.

Considerazioni sul pool di connessioni del database batch Java

Il runtime batch Java in generale segue un modello get - use - close quando viene effettuata una chiamata al database e generalmente non si attiene alle connessioni JDBC per un periodo più lungo rispetto al tempo in cui le utilizza. Ciò significa che la questione del numero di connessioni necessarie per eseguire un determinato numero di lavori e partizioni su un server è una decisione che viene quasi interamente presa dall'amministratore.

Non è necessario configurare la dimensione del pool di connessioni su un valore maggiore o uguale al numero di lavori e partizioni in esecuzione per evitare deadlock. Il conflitto di risorse, a causa di un numero insufficiente di connessioni, potrebbe ancora portare a prestazioni non ottimali. Ci sarà anche un numero minimo di connessioni richieste, probabilmente maggiore di 1, per eseguire percorsi speciali, come l'attivazione dei componenti batch. Gli amministratori possono iniziare con i valori predefiniti e utilizzare le metriche del lotto connessioni e il controllo, ad esempio, per bilanciare il consumo di risorse rispetto alle prestazioni.  Ciò si applica all'utilizzo runtime delle connessioni JDBC . Gli amministratori potrebbero ancora dover prendere in considerazione il pool di connessioni JDBC perché è utilizzato dal codice dell'applicazione.

Confronto tra creazione automatica e creazione manuale di tabelle di database

Per impostazione predefinita, il runtime batch crea automaticamente tabelle non esistenti nell'archivio database di persistenza batch.   Questo comportamento di creazione automatica predefinito estende anche le tabelle esistenti e la creazione di nuove colonne nei casi in cui è stata applicata la manutenzione che contribuisce a queste nuove definizioni di colonna.

In alternativa, lo script ddlGen può essere utilizzato per creare una DDL in base alla configurazione del server. Se necessario, la DDL può essere personalizzata prima di creare manualmente le tabelle. Questa DDL include anche la configurazione del server come schema e tablePrefix e contiene l'SQL appropriato per il tipo di database dell'origine dati a cui fa riferimento l'archivio database.

Nota: la DDL personalizzata deve utilizzare ID chiave primaria interi positivi. Come limitazione per la persistenza del database, Java Batch non accetta ID interi negativi o zero persistenti nelle colonne di identità della chiave primaria. Il runtime del contenitore Java Batch esegue solo i lavori che utilizzano ID lavoro interi positivi persistenti nelle colonne di identità della chiave primaria.

La creazione automatica delle tabelle può essere disabilitata utilizzando l'attributo createTables="false" in databaseStore. Questa opzione può essere utilizzata per assicurarsi di utilizzare tabelle create manualmente invece di utilizzare tabelle create automaticamente se il runtime batch non trova le tabelle create manualmente.

Per informazioni sulla creazione manuale delle tabelle personalizzando la DDL generata, incluse le possibili personalizzazioni, consultare il white paper Liberty Batch - Job Repository Configuration . Sebbene questo white paper sia per i sistemi operativi DB2® su z/OS® , è possibile che le informazioni siano utili per altri database e piattaforme.

Esempi di configurazione della persistenza

Archivio database predefinito con tabelle create automaticamente, configurate con il database Derby RUNTIMEDB:

<!-- Derby JDBC driver --> 
<library id="DerbyLib"> 
    <fileset dir="${server.config.dir}/resources/derby" /> 
</library> 

<!-- Data source for batch tables, and possibly other components. --> 
<dataSource id="DefaultDataSource"> 
    <jdbcDriver libraryRef="DerbyLib" /> 
    <properties.derby.embedded  
        databaseName="${server.config.dir}/resources/RUNTIMEDB"     
        createDatabase="create" 
        user="user" password="pass" /> 
</dataSource>

Archivio database specifico per batch con tabelle create manualmente, schema personalizzato, prefisso tabella, origine dati batch

<batchPersistence jobStoreRef="BatchDatabaseStore"/>

<!-- DB Store config only used by batch components -->
<databaseStore id="BatchDatabaseStore" dataSourceRef="BatchDS"
    createTables="false" schema="HLQ" tablePrefix="JB1"/> 

<!-- Data source for batch tables --> 
<dataSource id="BatchDS"> 
    <jdbcDriver libraryRef="DerbyLib" /> 
     ...
</dataSource>

Archivio database predefinito con configurazione auth, schema personalizzato, tabelle create automaticamente, origine dati predefinita:

<!-- DB Store used by batch and possibly other runtime components. --> 
<databaseStore id="defaultDatabaseStore" schema="HLQ">
    <authData user="user1" password="password1"/>  
</databaseStore>

<!-- Data source for batch tables, and possibly other components. --> <dataSource id="DefaultDataSource"> 
    <jdbcDriver libraryRef="DerbyLib" /> 
    ...
</dataSource>

Riferimento

Per una discussione sulla creazione manuale delle tabelle personalizzando la DDL generata, incluse le possibili personalizzazioni, consultare il white paper: https://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102716