[
https://issues.apache.org/jira/browse/CAMEL-7810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114025#comment-17114025
]
Federico Valeri commented on CAMEL-7810:
----------------------------------------
This is now fixed and works with every database. You can find [an example
here|https://github.com/apache/camel-examples/tree/master/examples/camel-example-aggregate-dist].
> 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)
