[
https://issues.apache.org/jira/browse/CAMEL-17613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin BONNET updated CAMEL-17613:
------------------------------------
Attachment: CAMEL-17613-log.txt
> camel-sql - Race condition in AggregateProcessor with Jdbc Repository
> ---------------------------------------------------------------------
>
> Key: CAMEL-17613
> URL: https://issues.apache.org/jira/browse/CAMEL-17613
> Project: Camel
> Issue Type: Bug
> Components: camel-core, camel-sql
> Affects Versions: 3.11.2
> Reporter: Benjamin BONNET
> Priority: Major
> Fix For: 3.16.0
>
> Attachments: CAMEL-17613-log.txt
>
>
> Hi,
> using aggregate with a JdbcAggregationRepository, we are encountering a race
> condition that may leave a completed exchange in completed table even after
> that completed exchange has been sent. Unfortunately, that leads to
> duplicates since recovery task will eventually try and recover it.
> Normally, when the exchange completes, it is deleted from repo exchange table
> and inserted into repo completed exchange table. Then exchange is sent and
> deleted from repo completed exchange table.
> But, due to the fact those two actions are run by different threads (and in
> different transactions) that order may vary.
>
> Here is a normal sequence :
> AggregateProcessor.doProcess
> doAggregation
> doAggregationComplete
> onCompletion
> JdbcAggregationRepository.remove : => INSERT ... INTO _completed
> onSubmitCompletion
> AggregateOnCompletion.onComplete (via executorService)
> JdbcAggregationRepository.confirm : => DELETE FROM _completed
> With the use of executorService, confirm is run by another thread and may
> commit before remove commits. Eventually, when that occurs, one can check
> that DELETE statement returns 0 (number of deleted rows) instead of 1.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
