Bug 4543

Summary: checkpointInfo should take a context of some kind
Product: jbatch Reporter: mminella
Component: sourceAssignee: cvignola
Status: RESOLVED WORKSFORME    
Severity: normal CC: issues
Priority: P5    
Version: 1   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard:

Description mminella 2013-01-17 21:19:27 UTC
In SB, there is an ExecutionContext associated with a JobExecution and a StepExecution.  The ExecutionContext is used to store information during the given scope (it is persisted and referred to on restarts).  We pass that context into each of the open and update methods on the ItemStream (ItemReader/ItemWriter's open/checkpointInfo methods).

open accepts an Externalizable which is the closes the spec comes to the ExecutionContext so that is ok.  However, the checkpointInfo does not take any type of context.  This means that the ItemReader/ItemWriter needs to be statefull so that it can provide a new Externalizable with each call.  This gets ugly at best when used in multiple threads.

I would say that since we are not binding the Externalizable to a given type, we should at least allow it to be passed to the checkpointInfo method to provide context.
Comment 1 cvignola 2013-01-23 21:49:25 UTC
JobContext and StepContext play the role of that JobExecution and StepExecution seem to in SB.  Note StepContext holds persistent user data.   The spec relegates JobExecution and StepExecution strictly to being repository objects and not available at runtime except if an application explicitly uses JobOperator to retrieve them.  

ItemReader/ItemWriter can manage their state without being stateful by using StepExecution, which they can access via field injection.  So there is no need to pass the context object.
Comment 2 mminella 2013-01-24 15:11:52 UTC
I'm not clear on the last comment:

1.  You state that the JobExecution and StepExecution are strictly repository objects and not available at runtime and are only accessible via the JobOperator.
2.  Yet you then say that an ItemReader/ItemWriter can manage their state via the StepExecution via injection.  

Do you mean the StepContext can be used for state management?
Comment 3 cvignola 2013-01-24 23:51:59 UTC
(In reply to comment #2)

Yes, I meant StepContext.  Sorry.

> I'm not clear on the last comment:
> 1.  You state that the JobExecution and StepExecution are strictly repository
> objects and not available at runtime and are only accessible via the
> JobOperator.
> 2.  Yet you then say that an ItemReader/ItemWriter can manage their state via
> the StepExecution via injection.  
> Do you mean the StepContext can be used for state management?
Comment 4 cvignola 2013-02-02 01:22:40 UTC
As I said,

ItemReader/ItemWriter can manage their state without being stateful by using
StepContext, which they can access via field injection.  So there is no need
to pass the context object.