Abort a tasklet without aborting Job

[katz_jd]

Under certain conditions, I'd like to throw an exception in a tasklet so that the tasklet aborts and the stepExecutionListener onErrorInStep method can do some stuff.

However, I do not wish to abort the entire job, but instead to have the job resume by invoking the next tasklet in the step list.

Any suggestions on how I might accomplish this? I am using Spring Batch 1.1.2.

Thanks.

[lucasward]

2.0 provides this feature inherently:

http://static.springsource.org/sprin...x.html#d0e2534

However, in 1.1, your only option is to stop the step early, but not through an exception, so that the job thinks the step was successful.

[katz_jd]

2.0 provides this feature inherently:

http://static.springsource.org/sprin...x.html#d0e2534

However, in 1.1, your only option is to stop the step early, but not through an exception, so that the job thinks the step was successful.

Thanks much for your quick reply Lucas.

Unfortunately, our goal was to use the onErrorInStep method in a custom listener to send an email and do some other logging, but that method is not invoked unless an exception is thrown.

I think I have another workaround, however:

1. Have the Tasklet implemet StepExecutionListener.
2. Implement a custom StepExecutionListener and register it.
3. On the error condition, have the tasklet put a value into the execution context that we can examine in the AfterStep method of our custom stepexecutionlistener, and then do the work there.

[DHGarrette]

There's no rule that says the listener has to be a separate class. You might make it easier on yourself by having the Tasklet itself implement StepExecutionListener. That way you wouldn't have to use the ExecutionContext to move the value around... it would already be on the class.

[katz_jd]

There's no rule that says the listener has to be a separate class. You might make it easier on yourself by having the Tasklet itself implement StepExecutionListener. That way you wouldn't have to use the ExecutionContext to move the value around... it would already be on the class.

I agree, but in our job we have many tasklets, and we'd like to have a central point from which to do our error processing, to make it uniform and reusable.

The primary objective will be to notify our support staff via email that something that was supposed to happen in one or more of the tasklets did not happen.

Unless we upgrade to 2.0, which at this time is not feasible, I guess I'm going to have to hack together a solution.

[lucasward]

You could use a inheritance? I understand your point about wanting to apply the same logging consistently, and if you have many tasklets, you may be able to apply it that way with a base class. I think it's preferable to use a separate class to accomplish your goal, and while I normally dislike using inheritance as an architecture mechanism rather than representing a true 'is a' relationship, it may be the best option in this case.

[katz_jd]

You could use a inheritance? I understand your point about wanting to apply the same logging consistently, and if you have many tasklets, you may be able to apply it that way with a base class. I think it's preferable to use a separate class to accomplish your goal, and while I normally dislike using inheritance as an architecture mechanism rather than representing a true 'is a' relationship, it may be the best option in this case.

Yes. Like you, I cringe at the thought of using inheritance this way, but otherwise I'll be forced to implement StepExecutionListener in each of the tasklets, and in each of the beforeStep methods initialize the StepExecution and ExecutionContext attributes.

When do you think 2.0 will be released into production?

[DHGarrette]

RC1 is expected on 2/13/09 and the full release will hopefully be in March.

You can track the dates in JIRA:
http://jira.springframework.org/brow...:roadmap-panel

[katz_jd]

I decided, in the end, to implement RepeatOperations (using RepeatTemplate) in each of my tasklets. This gave me the ability to create a custom exception handler to deal with the problem.

In the code I make sure the tasklets will only iterate once, regardless of whether they are successful or whether there is a problem.

This avoids the ugly hack of maintaining state in the step execution context and its need to have two listeners for the same tasklet.