I am developing batch job in java-ee-7 on top of liberty server. using the REST API to launch the batch job. The issue here is when I tried to launch the batch job for the same input parameter, new job instance getting created. Whereas spring batch process, throws an error saying JobInstanceAlreadyExistsException. I am expecting something like this to avoid new job been created for the same input parameter

The input parameter and batch status has been stored in persistent storage in Oracle database using the liberty server tables (WLPJOBINSTANCE, WLPSTEPTHREADINSTANCE, wlpjobparameter etc).

<job xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

    xmlns="http://xmlns.jcp.org/xml/ns/javaee"

    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/jobXML_1_0.xsd"

    id="my-batch-job" restartable="true" version="1.0">

</job>

Expected: Job should throw an exception if the same input parameter is passed.
Actual: Its creating new job instance for the same input parameter

Using Liberty Batch REST API to see if matching job instance already exists

I'm going to give a second, completely different answer here. The other answer justified why Liberty Batch, and more generally the JSR 352 specification, will never consider it an error case to submit a second job with the same job parameters as an earlier one.

But if you really wanted to prevent this, you can do this in Liberty Batch by using the REST API to query, before submission, if a matching job instance already exists. At this point, it will be up to you to abort/prevent the job submission, however.

Say I wanted to match jobName of BonusPayout, with job parameter parm1 of value 1000 and job parameter parm2 matching 500* (with glob/wildcard).

I could do this via URL:

https:///ibm/api/batch/v4/jobinstances?jobName=BonusPayout&jobParameter.parm1=1000&jobParameter.parm2=500*

Note in the doc there are various other options like ignoring case (or not).

So if I get a match, I can choose to NOT go ahead and submit the job (again).

The Liberty Batch implementation is working as designed, in accordance with the JSR 352 specification.

There is no way in Liberty Batch (or the JSR 352 spec) to prevent you from creating any number of Job Instances from a given job definition, and you would have to create your own mechanism for doing so.

The conceptual starting point in JSR 352 is a job definition for a job that typically will be run repeatedly according to some schedule: daily, monthly, quarterly, etc.

There is nothing in Liberty Batch or the spec to prevent you from starting a new job instance via the JobOperator start() method, or, using the Liberty Batch REST API, via a POST /ibm/api/batch/jobinstances/ because some similar job instance already exists.

You are prevented from restarting a job instance that has already completed but never from creating new job instances.

This is phrased another way in this answer and you'll find the spec concepts discussed in more detail here.

So whatever Spring Batch provides here is unique to its implementation.