LONG_VAL in BATCH_EXECUTION_CONTEXT

[Kmisaal]

Hi

LONG_VAL column in BATCH_EXECUTION_CONTEXT has inconsistent value with the ITEM_COUNT.

After the job is complete I see LONG_VAL has always 1 count more than the total number of records processed. I know that there was similar problem with the ITEM_COUNT. Following JIRA documents that

http://jira.springframework.org/browse/BATCH-531

Is there a posibility of having same problem with LONG_VAL in BATCH_EXECUTION_CONTEXT as I see it is always one count more than the total processed rows.

I am using spring batch 1.1.2.RELEASE

[Dave Syer]

If there is an issue (which I doubt) we would have to know which long value you are worried about. ExecutionContext is a set of name-value pairs. You have found a value which is correlated with the item count. If you didn't create the value yourself (what is its key name?), I would expect it to be irrelevant to your application because it will be an internal counter from one of the framework classes.

[Kmisaal]

Hey Dave

We don't create the LONG_VAL for ourself. We are looking at the value updated by spring batch.

The key is "JdbcCursorItemReader.read.count"

Which I think number of records read/processed at the end. In another thread we discussed what is meant by ITEM_COUNT.
ITEM_COUNT is also number of records read. See the following thread for more details.

http://forum.springframework.org/showthread.php?t=59385

So at the end of the job completion i.e successfully with zero records skipped I expect ITEM_COUNT
should match the LONG_VAL. However LONG_VAL is one count more than ITEM_COUNT.

Please correct me if my understanding is wrong

[lucasward]

This is the value stored by the JdbcCursorItemReader, which is why it makes sense that it's off, since it's related to the row in the resultset, and is completely oblivious to the number of items processed. It might be off just because it starts at 1 instead of 0. However, in the case of skipped records it could be wildly off. It doesn't matter though, it's simply there to keep track of the row for the reader so that it can restart correctly and has no bearing on anything else.