Dave Syer - 20/Apr/08 03:16 PM I am in favour of simplifying item reader implementations wherever possible. Putting the buffering responsibilities in an ItemHandler would be one way to do it, or even a third party (like a delegate item reader).

Robert Kasanicky - 29/Apr/08 07:57 AM Generic buffered item reader that wraps a delegate forward-only item reader seems straightforward to implement. ItemHandler could then do the wrapping so that users needn't declare the wrapper in xml (boilerplate). I think we can give it a try for 1.1?

Dave Syer - 02/May/08 03:06 AM The ItemHandler should be able to tell the difference between a reader that needs (or wants) to be buffered and one that doesn't. The JMS reader is the obvious case in point, but there may be generalisations. Does this also mean that mark() and reset() are no longer part of the ItemReader interface (would be nice)? Maybe an ItemReader just needs a boolean query method say whether it is transaction aware (the JMS case), or whether it needs the handler to buffer items.

Robert Kasanicky - 05/May/08 03:57 AM Yes, mark() and reset() should be unnecessary on ItemReader. Overall the changes seem quite significant, so scheduling for 2.0.

Dave Syer - 29/Aug/08 10:17 AM Already done as part of BATCH-789