为什么在 JSR 352 的 ItemWriter 接口中有一个 checkpointInfo？任何示例实施？
Why is there a checkpointInfo in ItemWriter interface for JSR 352? Any sample implementation?
为什么在Jsr 352 ItemWriter接口中有一个checkpointInfo方法。 reader 和作者如何就正在提交的内容进行沟通
作者无需使用 checkpointInfo() 方法。您可以简单地选择忽略 open() 和 return null 中的检查点值（如 AbstractItemWriter 所做的那样）。这很常见。通常，您不需要任何类型的 "cursor" 或索引来写入数据库，因为您只需 insert/update 无论 reader/processor 给您什么（基于 reader 检查点， ETC。）。
您可以在写入平面文件时使用检查点。由于文件写入通常不是事务性的，因此您需要以某种方式考虑到这一点。
一种简单的方法是将字节#/偏移量检查点放入文件中，位于最近块的末尾。因此，如果在您将记录 501-600 写入文件后块事务回滚，那么在重新启动时您将重新读取和重新处理记录 501-600。即使记录 501-600 已经存在于文件中，您现在将覆盖它们，因为您（重新）从记录 500 之后的字节位置开始。
由于不需要太频繁地重新启动，并且您只有一个块值得重新处理，因此这可以提供一种简单、可接受的方法来解决缺少事务资源的问题。
为什么在Jsr 352 ItemWriter接口中有一个checkpointInfo方法。 reader 和作者如何就正在提交的内容进行沟通
作者无需使用 checkpointInfo() 方法。您可以简单地选择忽略 open() 和 return null 中的检查点值（如 AbstractItemWriter 所做的那样）。这很常见。通常，您不需要任何类型的 "cursor" 或索引来写入数据库，因为您只需 insert/update 无论 reader/processor 给您什么（基于 reader 检查点， ETC。）。
您可以在写入平面文件时使用检查点。由于文件写入通常不是事务性的，因此您需要以某种方式考虑到这一点。
一种简单的方法是将字节#/偏移量检查点放入文件中，位于最近块的末尾。因此，如果在您将记录 501-600 写入文件后块事务回滚，那么在重新启动时您将重新读取和重新处理记录 501-600。即使记录 501-600 已经存在于文件中，您现在将覆盖它们，因为您（重新）从记录 500 之后的字节位置开始。
由于不需要太频繁地重新启动，并且您只有一个块值得重新处理，因此这可以提供一种简单、可接受的方法来解决缺少事务资源的问题。