Dear Camel Developers,
we from SAP use the Camel Aggregator Processor together with an persistent aggregation repository. Our aggregator functionality contains an additional persistent repository for incoming messages where we store additionally incoming messages which are going to be send to the aggregator. All this repository actions (for incoming messages and aggregation repository) has to happen in one transaction. In addition to that we use the Optimistic Locking Capability of the aggregator. But our logic was broken when we moved to Camel 3.x from Camel 2.x, because we recognized that the Optimistic Locking functionality was changed from synchronous retries to asynchronous retries in a different thread which broke our transaction logic, because we need to have a synchronous answer from the aggregator if the currently incoming message could be added to the corresponding aggregate in order to commit or rollback the currently open transaction. Hence in our own Camel fork we patched the aggregate Processor in a way that we reestablished the Camel 2.x synchronous Optimistic Locking Behaviour in Camel 3.x So our question/request would be if the standard aggregator Processor for Camel 3.x and higher could at least offer a configuration possibility to be able to choose between synchronous and asynchronous Optimistic locking behaviour. What do you think? We are happy to have further discussions on this. We can also provide a pull request containing a proposal how to include the desired behaviour in the aggregator if you wish. Many thanks and best regards, Manfred Schmid SAP SE
