diff --git a/spring-batch-infrastructure/src/main/java/org/springframework/batch/item/ItemReader.java b/spring-batch-infrastructure/src/main/java/org/springframework/batch/item/ItemReader.java
index ba0c81bcc..484301a50 100644
--- a/spring-batch-infrastructure/src/main/java/org/springframework/batch/item/ItemReader.java
+++ b/spring-batch-infrastructure/src/main/java/org/springframework/batch/item/ItemReader.java
@@ -19,13 +19,15 @@ package org.springframework.batch.item;
/**
* Strategy interface for providing the data.
*
- * Implementations are expected to be stateful and will be called multiple times for each batch, with each call to
- * {@link #next} returning a different value and finally returning null when all input data is exhausted.
+ * Implementations are expected to be stateful and will be called multiple times
+ * for each batch, with each call to {@link #next} returning a different value
+ * and finally returning null when all input data is exhausted.
*
- * Implementations need to be thread safe and clients of a {@link ItemReader} need to be aware that this is the case.
+ * Implementations need to be thread safe and clients of a {@link ItemReader}
+ * need to be aware that this is the case.
*
- * A richer interface (e.g. with a look ahead or peek) is not feasible because we need to support transactions in an
- * asynchronous batch.
+ * A richer interface (e.g. with a look ahead or peek) is not feasible because
+ * we need to support transactions in an asynchronous batch.
*
* @author Rob Harrop
* @author Dave Syer
@@ -35,9 +37,11 @@ package org.springframework.batch.item;
public interface ItemReader {
/**
- * Reads a piece of input data and advance to the next one. Implementations must return
- * null at the end of the input data set. In a transactional setting, caller might get the same item
- * twice from successive calls (or otherwise), if the first call was in a transaction that rolled back.
+ * Reads a piece of input data and advance to the next one. Implementations
+ * must return null at the end of the input
+ * data set. In a transactional setting, caller might get the same item
+ * twice from successive calls (or otherwise), if the first call was in a
+ * transaction that rolled back.
*
* @throws Exception if an underlying resource is unavailable.
*/
@@ -46,22 +50,30 @@ public interface ItemReader {
/**
* Mark the stream so that it can be reset later and the items backed out.
*
- * In a multi-threaded setting implementations have to ensure that only the state from the current thread is saved.
+ * Mark is called before reading a new chunk of items - in case of rollback
+ * mark will not be called again before re-processing the chunk.
*
- * @throws MarkFailedException if there is a problem with the mark. If a mark fails inside a transaction, it would
- * be worrying, but not normally fatal.
+ * In a multi-threaded setting implementations have to ensure that only the
+ * state from the current thread is saved.
+ *
+ * @throws MarkFailedException if there is a problem with the mark. If a
+ * mark fails inside a transaction, it would be worrying, but not normally
+ * fatal.
*/
void mark() throws MarkFailedException;
/**
- * Reset the stream to the last mark. After a reset the stream state will be such that changes (items read or
- * written) since the last call to mark will not be visible after a call to close.
+ * Reset the stream to the last mark. After a reset the stream state will be
+ * such that changes (items read or written) since the last call to mark
+ * will not be visible after a call to close.
*
- * In a multi-threaded setting implementations have to ensure that only the state from the current thread is reset.
+ * In a multi-threaded setting implementations have to ensure that only the
+ * state from the current thread is reset.
*
- * @throws ResetFailedException if there is a problem with the reset. If a reset fails inside a transaction, it
- * would normally be fatal, and would leave the stream in an inconsistent state. So while this is an
- * unchecked exception, it may be important for a client to catch it explicitly.
+ * @throws ResetFailedException if there is a problem with the reset. If a
+ * reset fails inside a transaction, it would normally be fatal, and would
+ * leave the stream in an inconsistent state. So while this is an unchecked
+ * exception, it may be important for a client to catch it explicitly.
*/
void reset() throws ResetFailedException;
diff --git a/spring-batch-infrastructure/src/main/java/org/springframework/batch/item/file/FlatFileItemReader.java b/spring-batch-infrastructure/src/main/java/org/springframework/batch/item/file/FlatFileItemReader.java
index 2a34d2840..92c3881ec 100644
--- a/spring-batch-infrastructure/src/main/java/org/springframework/batch/item/file/FlatFileItemReader.java
+++ b/spring-batch-infrastructure/src/main/java/org/springframework/batch/item/file/FlatFileItemReader.java
@@ -221,6 +221,7 @@ public class FlatFileItemReader extends ExecutionContextUserSupport implements I
*/
public void mark() {
getReader().mark();
+ skippedLines.clear();
}
/*