WildFly ships with a subsystem named batch which is the administration side of JSR 352, also known as Batch API for Java applications. This JSR specifies a programming model for batch applications and a runtime for scheduling and executing jobs.
WildFly Batch Job Repository configuration
Out of the box, the following configuration is included:
<subsystem xmlns="urn:jboss:domain:batch:1.0"> <job-repository> <in-memory/> </job-repository> <thread-pool> <max-threads count="10"/> <keepalive-time time="30" unit="seconds"/> </thread-pool> </subsystem>
In terms of configuration, whatâ€™s worth to know is that Job executions are stored in a repository, which enables querying of current and historical job status. The default location of the job repository is in-memory which means that you can query the repository programmatically using the Batch API. On the other hand, if you want to inspect the Job Repository using typical administration tools, then you can opt for using a JDBC Repository which can then be queried using standard SQL commands.
Another important advantage of using a JDBC Job Repository is that you will be able to restart your jobs from the point they left off, in case of application server failure.
Setting the job repository to use JDBC is just a matter of executing a couple of CLI commands:
/subsystem=batch/:write-attribute(name=job-repository-type,value=jdbc) /subsystem=batch/job-repository=jdbc/:write-attribute(name=jndi-name,value=java: /MySQLDS)
This reflects in the following configuration:
<subsystem xmlns="urn:jboss:domain:batch:1.0"> <job-repository> <jdbc jndi-name="java:/MySQLDS"/> </job-repository> <thread-pool> <max-threads count="10"/> <keepalive-time time="30" unit="seconds"/> </thread-pool> </subsystem>
In this example, we are setting the job repository to use the datasource which is bound to the java:/MySQLDS JNDI namespace that you must have defined in your datasource section. Once that you have a JDBC repository, then once that you initialize the Batch API with some jobs, the tables will be automatically created:
You can query for the Jobs which have been executed by a particular application through the JOB_INSTANCE table:
On the other hand if you want some execution details about jobs, then you can query the JOB_EXECUTION table:
I’d like to express my gratitude to Cheng Fang (JBeret project Lead) for providing useful insights for writing this article.