May 14th, 2007, 12:41 PM
Restart of bean-managed MDB
This is a real value-add to many projects! Great news. How much of the re-start challenge facing MDB-triggered multi-commit batches is solved out-of-the-box? Thinking of a batch processing a large inbound message, committing every 10 logical messages, hit by a server crach. After start-up the roll-backed message hits the business logic a second time, which needs to fast-forward to the first logic record of the roll-backed transaction.
May 23rd, 2007, 03:31 AM
Part of the purpose of Spring Batch infrastructure is to provide simple (but extremely effective) optimisations of the sort you describe. There is a MessageListenerContainer that might meet your needs.
Also it is relatively simple to roll your own container using the underlying infrastructure and get even more control over the commit / exception handling. There are currently some integration tests that demonstrate this kind of approach, and it is also being tested by a client. If there is sufficient demand and we can add some value we will solidify the basic messaging container in the product.
If you want a message-based / staged / pipeline-oriented architecture, and also need traceability, monitoring and management of job instances, you will be interested in the idea of a container based on an ESB (e.g. Mule). We are definitely also going to be working on that, but not just yet.