ItemReaders和ItemWriters - ItemStream

ItemReader 和 ItemWriter 都为各自的目的服务, 但他们之间有一个共同点, 就是都需要与另一个接口配合。 一般来说,作为批处理作业作用域范围的一部分,readers 和 writers 都需要打开(open),关闭(close),并需要某种机制来持久化自身的状态:

public interface ItemStream {
    void open(ExecutionContext executionContext) throws ItemStreamException;
    void update(ExecutionContext executionContext) throws ItemStreamException;
    void close() throws ItemStreamException;
}

在描述每种方法之前, 我们应该提到ExecutionContext。 ItemReader的客户端也应该实现 ItemStream, 在任何 read 之前调用 open 以打开需要的文件或数据库连接等资源。 实现ItemWriter也有类似的限制/约束,即需要同时实现ItemStream。 如第2章所述,如果将数据存放在ExecutionContext 中, 那么它可以在某个时刻用来启动 ItemReader 或 ItemWriter,而不是在初始状态时。 对应的, 应该确保在调用 open 之后的适当位置调用 close 来安全地释放所有分配的资源。 调用 update 主要是为了确保当前持有的所有状态都被加载到所提供的 ExecutionContext中。 update 一般在提交之前调用, 以确保当前状态被持久化到数据库之中。

在特殊情况下, ItemStream 的客户端是一个 Step(由 Spring Batch Core 决定), 会为每个 StepExecution 创建一个 ExecutionContext，以允许用户存储特定部分的执行状态, 一般来说如果同一个JobInstance重启了,则预期它将会在重启后被返回。 对于熟悉 Quartz的人来说, 逻辑上非常像是 Quartz 的 JobDataMap。