Hi Claus, Thanks for the quick reply. Then we will proceed as you have suggested.
Best regards, Manfred -----Original Message----- From: Claus Ibsen <[email protected]> Sent: Thursday, 25 September 2025 21:10 To: [email protected] Subject: Re: Optimistic Locking Behaviour of Aggregator Processor [You don't often get email from [email protected]. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] Hi Yeah sure you are welcome to create a JIRA and send a PR for the main branch. On Thu, Sep 25, 2025 at 5:21 PM Schmid, Manfred <[email protected]> wrote: > 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 > > -- Claus Ibsen
