Hi Yes sure that is the way.
On Mon, Apr 20, 2026 at 1:04 PM Becker, Marcel via dev <[email protected]> wrote: > 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 > -- Claus Ibsen
