Dear Camel Community, this is a follow-up to the mail sent in September 2025 regarding the feature request for configurable synchronous/asynchronous Optimistic Locking in the AggregateProcessor. (See on the mail thread )
I have now taken over this task and would like to move it forward. To confirm: we would create a JIRA ticket and submit a PR against the main branch with the proposed configuration option — as suggested in the earlier response. Could you please confirm that this is still welcome and that the approach (JIRA + PR against main) is still the right way to proceed? Thank you and best regards, Marcel Becker -----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
