Bugzilla – Full Text Bug Listing
|Summary:||How is the completion of flows/splits persisted and treated on restart?|
Description ScottKurz 2012-11-21 13:18:29 UTC
Assuming the overall approach outlined in Bug 4098 (decision logic reruns on restart, application logic typically doesn't), there are a couple of reasons why we need to be clear on whether it's meaningful to consider a flow or a split as having already completed on restart. Take a flow for example, and assuming that there is no meaning attach to "flow already completed". So for one: intra-flow decision logic rerunning could take us down a different path than during the original run, even if the flow had "completed" successfully. Second: allow-start-if-complete steps that were branched to would rerun on restart. On the other hand, couldn't we treat a persisted "flow completed" as a signal to simply skip the flow internals, and transition to the @next id, and still have a coherent story? (I realize this gets tricky if we have a decider but I'm going to open a separate issue for that). Do we need an allow-start-if-complete equivalent for flow (that could get complicated...not trying to introduce it if no one thinks it will be used in real world scenarios)? --- I noticed in Comment 3, Bug 4273 mminella touched on this question from another angle, saying that SpringBatch doesn't treat splits/flows as "first class" executions in this regard.
Comment 1 cvignola 2012-12-07 00:04:40 UTC
Regarding 4098, we are eliminating job parameters on restart, so some aspects of what this bug brings up go away. Regarding persisting some information that a flow is complete to assist with restart logic - that fine, but not a spec issue - that should remain an implementation detail. Regarding something like a allow-start-if-completed for a flow - no - we need to stay focused on whether or not individual steps are allowed to start or not.