[ https://issues.apache.org/jira/browse/CAMEL-7810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Claus Ibsen resolved CAMEL-7810. -------------------------------- Resolution: Fixed > Dropped exchanges when aggregating with JdbcAggregationRepository > ----------------------------------------------------------------- > > Key: CAMEL-7810 > URL: https://issues.apache.org/jira/browse/CAMEL-7810 > Project: Camel > Issue Type: Improvement > Components: camel-sql > Affects Versions: 2.13.2 > Reporter: K Smith > Priority: Major > Fix For: 2.25.2, 3.4.0 > > > Part 2 of CAMEL-6144 > bq. A similar Race condition happens when more than one Camel Aggregator(s) > tries to update a row in the AGGREGATION table. This problem does not lead > into any exceptions. But it leads into missing exchanges. Because both the > Aggregator's are trying to update the same row in the AGGREGATION table, But > one update is overwritten by other update, thus losing an exchange. > Simple example: > * I'm awaiting completion based on counting 5 messages. > * The current data in the aggregation table indicates 3 have been aggregated > so far. > * If I have either two threads or two process with a camel route that listens > to a queue and then aggregates: > ** thread one gets the existing message from the aggregation table (#3) > ** thread two gets the existing message from the aggregation table (#3) > ** thread one aggregates and adds its message to the aggregation table (#4) > ** thread two does the same then I've lost the message from thread one > But there is no exception in this case – the optimistic lock is only on the > message key, there's no versioning going on. -- This message was sent by Atlassian Jira (v8.3.4#803005)