gupabhi
Mar 17th, 2008, 06:35 PM
Hi,
I will try and explain my usecase and hope someone can tell me how I can use Spring Batch solve that
I need to read items from JMS and process them. (I am using ItemProvider and ItemProcessor interfaces to do this using the ItemProviderRertryPolicy.)
When an exception occurs during processing (in the ItemProcessor) it is either an expected exception (recoverable) or an unexpected exception (need to put in the error queue).
Case 1 - Recoverable Exception: It should simply not commit the transaction and the item will remain in the JMS/MQ queue and the item will be reread and reprocessed later.
Case 2 - Irrecoverable Exception: It needs to be put in the error queue. I get the control in this case in the recover() method of the provider. But if I put the message in the error queue here (and then commit), the problem is that partial processing might have happened in the processor before the exception was thrown and that will get committed.
Questions:
1. What do we do in the above case 2 ? Ideally that transaction should be rolledback and when the item is re-read the information that an irrecoverable exception occursed should be saved somwhere and the recover method should be called then. Is this what happnes?
2. My doubts are really around at which points should transactions be started/commited/rolledback in normal as well as exceptional scenarios.
3. Also, does the context maintain state of the items across retries? How does this work and how should I use this? Is there any simple example/reference code that I can see.
If any of questions/explanations is not clear please let me know and I will try to explain it again.
Thanks,
Abhi
I will try and explain my usecase and hope someone can tell me how I can use Spring Batch solve that
I need to read items from JMS and process them. (I am using ItemProvider and ItemProcessor interfaces to do this using the ItemProviderRertryPolicy.)
When an exception occurs during processing (in the ItemProcessor) it is either an expected exception (recoverable) or an unexpected exception (need to put in the error queue).
Case 1 - Recoverable Exception: It should simply not commit the transaction and the item will remain in the JMS/MQ queue and the item will be reread and reprocessed later.
Case 2 - Irrecoverable Exception: It needs to be put in the error queue. I get the control in this case in the recover() method of the provider. But if I put the message in the error queue here (and then commit), the problem is that partial processing might have happened in the processor before the exception was thrown and that will get committed.
Questions:
1. What do we do in the above case 2 ? Ideally that transaction should be rolledback and when the item is re-read the information that an irrecoverable exception occursed should be saved somwhere and the recover method should be called then. Is this what happnes?
2. My doubts are really around at which points should transactions be started/commited/rolledback in normal as well as exceptional scenarios.
3. Also, does the context maintain state of the items across retries? How does this work and how should I use this? Is there any simple example/reference code that I can see.
If any of questions/explanations is not clear please let me know and I will try to explain it again.
Thanks,
Abhi