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/02/08 10:07:00 UTC

[jira] [Commented] (CAMEL-17613) Race condition in AggregateProcessor with Jdbc Repository

    [ https://issues.apache.org/jira/browse/CAMEL-17613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17488721#comment-17488721 ] 

Claus Ibsen commented on CAMEL-17613:
-------------------------------------

Oh that is a great analysis. 

> 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
>
> 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)