code-massel opened a new pull request, #22769:
URL: https://github.com/apache/camel/pull/22769

   When optimisticLocking is enabled, retries are normally scheduled 
asynchronously on a background ScheduledExecutorService, which switches threads 
and breaks transactional use cases where the aggregation repository and inbound 
message store must commit/rollback within a single transaction boundary.
   
   The new syncOptimisticRetry flag (default false) causes the retry delay to 
execute via Thread.sleep on the calling thread instead, preserving the 
transaction context. This restores the Camel 2.x behavior for users who need 
it, without changing the default async behavior.
   
   # Description
   
   When `optimisticLocking` is enabled on the Aggregate EIP, retry failures are 
scheduled asynchronously on a background `ScheduledExecutorService`. This 
thread switch breaks transactional use cases where the aggregation repository 
and inbound message store must commit/rollback within a single transaction 
boundary (transaction context is bound to the originating thread).
   
   This PR adds a new `syncOptimisticRetry` option (default `false`) to the 
`aggregate` EIP. When enabled, the retry delay runs via `Thread.sleep` on the 
calling thread instead of scheduling on a background executor, preserving the 
transaction context. Default is `false` so existing routes are unaffected.
   
   # Target
   
   - [x] I checked that the commit is targeting the correct branch (Camel 4 
uses the `main` branch)
   
   # Tracking
   - [ ] If this is a large change, bug fix, or code improvement, I checked 
there is a https://issues.apache.org/jira/browse/CAMEL-23352 filed for the 
change.
   
   # Apache Camel coding standards and style
   
   - [ x] I checked that each commit in the pull request has a meaningful 
subject line and body.
   
   - [ x] I have run `mvn clean install -DskipTests` locally from root folder 
and I have committed all auto-generated changes.
   
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to