4.3. Function Comparison Between JSR-compliant Batch Application and Nablarch Batch Application

This section compares the following features:

Function comparison (JSR: Defined in JSR specifications A: Provided B: Partially provided C: Not provided D: Not applicable)
Function Compliant with JSR352 [1] Nablarch batch
Arbitrary parameters can be configured at startup JSR A
To the manual
Simultaneous execution of the same batch applications can be prevented A
To Javadoc		 A
To the manual
Batch applications that are running, can be safely stopped from the outside JSR A
To the manual
The maximum number of records to be processed in one execution can be specified. C
[2]		 A
To the manual
A fixed number of record units can be committed JSR A
To the manual
Can re-run from the point of failure JSR B
[3]
Business processes can be executed in parallel by multiple threads JSR A
To the manual
Processing can be continued ignoring specific exceptions (processing can be continued after rollback) JSR C
[4]
Processing can be retried when a specific exception occurs JSR B
[5]
The process to be executed next can be switched based on the batch application result JSR C
[6]
Batches can be executed by monitoring input data sources at regular intervals C [7] A
To the manual
[1]JSR parts are in accordance with the specifications defined in JSR352. For details, refer to the specification of JSR352 (external site).
[2]The property to specify the maximum number to read in a single run can be included in the implementation class ItemReader.
[3]Re-execution from the point of failure is possible by using ResumeDataReader (read with resume function). However, this feature is available only when a file is input. When other data is input, design and implementation are required in the application.
[4]Add a handler to continue processing ignoring specific exceptions.
[5]

Retry Handler retries for exceptions that can be retried, but a simple retry cannot be performed for data where an exception has occurred, as in JSR352. Exceptions to be retried cannot be specified flexibly with Retry Handler.

If the requirements cannot be met with the Retry Handler (simple retry of the data where the exception occurred or to specify the exception flexibly), provide support by adding a handler.
[6]Use a job scheduler, etc. For example, taking measures such as switching the job to be executed next based on the exit code will be necessary.
[7]In JSR352-compliant batch applications, it is not possible to realize a batch process for monitoring an input data source at regular intervals. For this reason, if such a batch application is necessary, realize using the resident batch of Nablarch batch application.