From f0d7c7135e1c87c6a95ff3363c077e9bd31b62ae Mon Sep 17 00:00:00 2001 From: robokaso Date: Tue, 25 Mar 2008 09:01:25 +0000 Subject: [PATCH] RESOLVED - issue BATCH-495: readers must not clear buffers on mark() http://jira.springframework.org/browse/BATCH-495 - updated mark() javadoc to state mark() is called only before processing new chunk, not before reprocessing - FlatFileItemReader modified to clear the skipped items buffer on mark --- .../batch/item/ItemReader.java | 46 ++++++++++++------- .../batch/item/file/FlatFileItemReader.java | 1 + 2 files changed, 30 insertions(+), 17 deletions(-) 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(); } /*