I have a scenario that I think is just outside the scope of spring-batch, but would like to explain my case and see if anyone has any ideas. I have a batch workflow like this:
- Load flat file into database
- Send message to another system to start doing its work
- Wait for other system to finish work (let's say that I can poll a database table to wait for a status flag to become a certain value)
- once other system is finished, then move to the next step in my job which reads some database records and writes a file
I've thought of these two approaches: 1. Split the above workflow into two spring batch jobs: one for steps 1-2 and another for step 4. Have some other process do the database polling to trigger the second job. 2. Do the polling inside of a tasklet that sleeps and then polls and returns a status indicating whether or not we need to poll again.
Option 1 is ok except that now I lose the ability to monitor the status of the overall "job" that I have. I'll have to create my own UOW progress monitoring that is tracking the individual spring-batch jobs.
Option 2 eats up a thread for each job. If I have hundreds of jobs that might be waiting at once I don't really want each polling individually and eating up a thread just to sleep.
I know the commercial workflow engine Flux has the concept of a workflow that hits a "wait" point that needs to be signalled externally and then it resumes. That would work well -- have some kind of external process (one thread) that is getting the set of jobs in a wait state, polling to see if any are ready to move on, and signalling the ones that are. Then spring batch picks up and continues on to the next step in the job.
Maybe I can approximate something by failing the job and having it restart? But then i can't tell the difference between a real failed job and just normal "wait" states in the spring batch admin web app.
Any clever ideas? Anyone know of any plans to add such functionality to spring-batch?