You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Claus Ibsen (Jira)" <ji...@apache.org> on 2022/03/07 09:06:00 UTC
[jira] [Updated] (CAMEL-17613) camel-sql - Race condition in AggregateProcessor with Jdbc Repository
[ https://issues.apache.org/jira/browse/CAMEL-17613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Claus Ibsen updated CAMEL-17613:
--------------------------------
Fix Version/s: 3.17.0
(was: 3.16.0)
> 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.17.0
>
> Attachments: CAMEL-17613-log.txt, Spring_jdbc_transactions.log
>
>
> 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)