JehanJaleel (2) [Avatar] Offline
#1
Hi,

Supposing I have an ItemReader similar to what you had specified in the first chapter of your book which just reads some data from a flat file. Now supposing I want to restart this job after an exception, and I want to restart at exactly where it left off before the exception was thrown. You said in page 204 that "the item reader must implement the restart logic". Are you sure I have to do this? Why cannot Spring Batch take care of this for me based on the information stored in the job repository tables. It knows I am reading a flat file and it knows where it was before the exception was thrown.

Related to this is that right now the job launcher is only throwing an exception, I want to it return with a status of "Failed". Is there anything I have to change in the configuration for it behave this way. Right now my code is exactly like the first chapter of the book, just a simple ItemReader/ ItemWriter job.

Thanks for any help,
Jehan
arnaud.cogoluegnes (73) [Avatar] Offline
#2
Re: Restarting a job after exception
Hi, Jehan.

In the case of the FlatFileItemReader of the first chapter, you have nothing to do for a restart, as this ItemReader implementation is restartable.

You're right when you say Spring Batch knows how many items have been read in the previous, failed execution. So, on a restart, the framework says to the ItemReader "hey, we're restarting, here is some information about the previous, failed execution", but that's pretty much it. That's the ItemReader's responsibility to resume exactly where it left off. Indeed, this is really implementation-dependent: this is a line for a flat file item reader, a specific row for a JDBC paging reader, etc. Spring Batch has only some callbacks for that, thanks to the ItemStream interface, and the ItemReader must implement the resume strategy in these callbacks.

If you want the JobLauncher not to launch an exception, I would recommend to write a wrapper that would "swallow" (and log!) execution exceptions. Be very careful with this: swallow only execution exception (thrown from readers writers, etc.), not exception like JobExecutionAlreadyRunningException, or you would break the JobLauncher contract.