Configuración de la persistencia de proceso por lotes de Java

El proceso por lotes Java™ utiliza un almacén persistente para persistir el estado, los puntos de comprobación y los datos persistentes de la aplicaciones entre varias ejecuciones de una instancia de trabajo. El almacén persistente permite reiniciar una instancia de trabajo si una ejecución anterior falla o debe detenerse proporcionando el trabajo reiniciado con los datos adecuados.

Configuración de la persistencia de proceso por lotes basada en memoria de Java

La persistencia por lotes permite reiniciar una instancia de trabajo si la ejecución finaliza con un estado FAILED o ERROR. En caso de no existir una configuración de persistencia de proceso por lotes, los procesos por lotes Java se apoyan de forma predeterminada en una persistencia basada en memoria para hacer un seguimiento del estado, de los puntos de comprobación y de los datos persistentes de aplicación entre varias ejecuciones de una instancia de trabajo.

Nota: La persistencia basada en memoria predeterminada tiene una limitación tan evidente como significativa.  Si la JVM del servidor o del entorno de ejecución del contenedor por lotes se cae o se reinicia, la persistencia se pierde.Esta función sólo está destinada a utilizarse para el desarrollo y no debe tenerse en cuenta para sistemas de producción o para el soporte de proceso por lotes crítico.

Configuración de la persistencia de proceso por lotes en base de datos de Java

La persistencia por lotes puede configurarse mediante un almacén de base de datos.  El almacén de base de datos referencia un origen de datos, que a su vez referencia un controlador JDBC, una ubicación de base de datos específica y otras propiedades personalizadas de base de datos.Los nombres calificados de las tablas de persistencia por lotes pueden configurarse utilizando los atributos schema y tablePrefix del propio almacén de base de datos.

Se proporciona un almacén de base de datos predeterminado llamado defaultDatabaseStore y se activa configurando el origen de datos predeterminado, llamado DefaultDataSource.

O bien, se puede configurar un almacén de base de datos distinto usando un elemento databaseStore y configurar la persistencia por lotes para que lo use añadiendo un elemento

batchPersistence con un atributo jobStoreRef que referencie el databaseStore.

Consideraciones sobre las agrupaciones de conexiones de base de datos por lotes de Java

El entorno de ejecución por lotes de Java suele atenerse al patrón obtener-usar-cerrar cuando se realiza una llamada a la base de datos y no suele retener las conexiones JDBC más tiempo del que las usa.Esto significa que la cuestión del número de conexiones necesarias para ejecutar un determinado número de trabajos y particiones en un servidor es una decisión que queda casi totalmente en manos del administrador.

No es necesario configurar el tamaño de la agrupación de conexiones para que sea mayor o igual que el número de trabajos y particiones en ejecución para evitar puntos muertos. No obstante, una contención de recursos debida a un número excesivamente bajo de conexiones podría dar lugar a un rendimiento por debajo del óptimo. También habrá un número mínimo de conexiones necesarias, probablemente superior a 1, para ejecutar rutas especiales como, por ejemplo, la activación de los componentes por lotes. Los administradores pueden empezar con los valores predeterminados y utilizar, por ejemplo, las métricas y la supervisión de las agrupaciones de conexiones para equilibrar el consumo de recursos con el rendimiento.  Esto se aplica a la utilización del entorno de ejecución de las conexiones JDBC. Puede que los administradores aún necesiten considerar la agrupación de conexiones JDBC, porque la use el código de aplicación.

Creación manual de tablas de base de datos versus creación automática

De forma predeterminada, el entorno de ejecución por lotes crea de forma automática tablas no existentes en el almacén de base de datos de persistencia por lotes. Este comportamiento de creación automática predeterminado también amplía las tablas existentes y la creación de nuevas columnas en los casos donde se ha aplicado un mantenimiento que contribuye a dichas definiciones de columna nuevas.

De forma alternativa, se puede utilizar el script ddlGen para generar un DDL en la configuración del servidor. Si es necesario, se puede personalizar el DDL antes de crear manualmente las tablas. Este DDL también incorpora la configuración de servidor como, por ejemplo, schema y tablePrefix, y contiene el SQL adecuado al tipo de base de datos del origen de datos referenciado por el almacén de base de datos.

Nota: El DDL personalizado debe utilizar ID de clave primaria que sean enteros positivos. Como limitación de la persistencia de base de datos, el proceso por lotes Java no acepta identificadores enteros negativos o cero persistidos en las columnas de identidad de clave primaria. El entorno de ejecución del contenedor de proceso por lotes Java solo ejecuta trabajos que utilizan identificadores de trabajo enteros positivos persistidos en las columnas de identidad de clave primaria.

La creación automática de tablas se puede inhabilitar utilizando el atributo createTables="false" en databaseStore. Esta opción puede utilizarse para garantizar que se usen tablas creadas manualmente en lugar de usar tablas creadas automáticamente si el entorno de ejecución por lotes, de forma inesperada, no puede encontrar las tablas creadas manualmente.

Para obtener más información sobre cómo crear manualmente las tablas personalizando el DDL generado, incluyendo posibles personalizaciones, consulte el libro blanco Procesos por lotes de Liberty - Configuración del repositorio de trabajos. Aunque este libro blanco es de DB2 sobre sistemas operativos z/OS, la información podría ser útil para otras bases de datos y plataformas.

Ejemplos de configuración de persistencia

Almacén de base de datos predeterminado con las tablas creadas automáticamente configuradas con RUNTIMEDB de la base de datos Derby:

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

<!-- Origen de datos de las tablas por lotes y puede que otros componentes. --> 
<dataSource id="DefaultDataSource"> 
    <jdbcDriver libraryRef="DerbyLib"/> 
    <properties.derby.embedded  
        databaseName="${server.config.dir}/resources/RUNTIMEDB"     
        createDatabase="create" 
        user="user" password="pass" /> 
</dataSource> 

Almacén de base de datos específico de lotes con tablas creadas manualmente, esquema personalizado, prefijo de tabla y origen de datos por lotes

<batchPersistence jobStoreRef="BatchDatabaseStore" />

<!-- Configuración de almacén de DB usada solo por componentes por lotes -->
<databaseStore id="BatchDatabaseStore" dataSourceRef="BatchDS"
    createTables="false" schema="HLQ" tablePrefix="JB1"/> 

<!-- Origen de datos de tablas por lotes --> 
<dataSource id="BatchDS"> 
    <jdbcDriver libraryRef="DerbyLib"/> 
     ...
</dataSource> 

Almacén de base de datos predeterminado con configuración automática, esquema personalizado, tablas creadas automáticamente, origen de datos predeterminado:

<!-- Almacén de BD usado por lotes y posiblemente por otros componentes del entorno de ejecución. --> 
<databaseStore id="defaultDatabaseStore" schema="HLQ">
    <authData user="user1" password="password1"/>  
</databaseStore>

<!-- Origen de datos de las tablas por lotes y puede que otros componentes. --> <dataSource id="DefaultDataSource"> 
    <jdbcDriver libraryRef="DerbyLib"/> 
    ...
</dataSource> 

Referencia

En el libro blanco https://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP102716 puede obtener un debate sobre la creación manual de tablas personalizando el DDL generado, incluyendo posibles personalizaciones


Icono que indica el tipo de tema Tema de referencia

Nombre de archivo: rwlp_batch_persistence_config.html