reset commit interval from reader/processor job, commit, processor, default, change

amy

Hello,

Quoting from the order job in samples. My case is lets say by default the commit-interval for the job is 100.
If the items in my order crosses certain limit say 1000, i want to change the commit-interval to 1 in those cases, if items are less than 1000, it needs to use the commit-interval of 100.

Can i reset the configured commit interval inside my reader or a processor? if so how?

Thanks
Srinivas

Use a custom CompletionPolicy in your chunk declaration, and inject the same policy into the processor.

Thanks Dave.
I have defined a completion policy, how do i get hold of the just read data returned by the reader inside the policy?
One way it seems it can be done is i can store the object read from reader inside the execution context and in the custom policy, i can get it via step execution.
But is there a better way? this seems like the same data is duplicated by me manually by storing it in execution context and in the infrastructure the chunk processor holds it somewhere?

Why do you need a reference to the item (I thought you needed the count)?  Anyway if you just do as I suggest and inject the CompletionPolicy into your ItemProcessor, you can make the decision there without saving the item anywhere, can't you?  Or you could make your ItemProcessor implement CompletionPolicy.

This is my view of the chunk processingchunk      Reader -gt; 1 order with items      Processor -gt; 1 order  chunk completion policy is at chunk level?        Check the items size, if items lt; maxSize, continue reading 2nd order

I implemented a policy but didnt use any processor in front of my writer.
And my intention was to check for the size of the items inside my policy.

As you stated if i do have processor implementing the chunk policy, i would need to store a instance level variable inside processor, so that i can use it when the isCompleted method is called?
And then clean up the instance variable at some point.
Does that sound right?

Thanks for your time


Originally Posted by srinivas_vskAs you stated if i do have processor implementing the chunk policy, i would need to store a instance level variable inside processor, so that i can use it when the isCompleted method is called?
And then clean up the instance variable at some point.
Does that sound right?

I haven't really understood the use case yet, but that does sound like a possible implementation (you would use step scope to protect the instance from other executions).  Some state has to be stored somewhere - ideally only in the RepeatContext, but you might only be able to implement your logic with an instance variable.

Somehow i feel that there should be a way for the chunk processor to inject the current chunk in to the chunk completion policy.
So the framework can pass what it is trying to commit to the policy optionally?
Thoughts?

I maybe off but the instance variable thing im goin to try next.

Thanks
Srinivas

There is a back door called RepeatSynchronizationManager which you can use inside a chunk to grab the current repeat context and force it to complete - instead of using an instance variable you would simply pull the current value from thin air as if by magic.  I would consider that an extreme measure - not very transparent to the configuration or the business code - but it would work in your use case (i.e. you can always force a commit).

Interesting think it will work for my case. Thanks Dave, Appreciate your help