[jira] [Updated] (CAMEL-11223) camel-jpa doesn't handle exclusive locks for concurrent consumers

["TEIKITEETINI-VAYSSE Loic (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CAMEL-11223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

TEIKITEETINI-VAYSSE Loic updated CAMEL-11223:
---------------------------------------------
    Environment: 
Java JDK  1.8.0_121
Spring 4 (reproduced with Spring Boot 1.5.3)
RedHat RHEL 7.1 x86_64
Oracle 11G

  was:
Java JDK  1.8.0_121
Spring 4 (reproduced with Spring Boot
RedHat RHEL 7.1 x86_64
Oracle 11G


> camel-jpa doesn't handle exclusive locks for concurrent consumers
> -----------------------------------------------------------------
>
>                 Key: CAMEL-11223
>                 URL: https://issues.apache.org/jira/browse/CAMEL-11223
>             Project: Camel
>          Issue Type: Improvement
>          Components: camel-jpa
>    Affects Versions: 2.18.3
>         Environment: Java JDK  1.8.0_121
> Spring 4 (reproduced with Spring Boot 1.5.3)
> RedHat RHEL 7.1 x86_64
> Oracle 11G
>            Reporter: TEIKITEETINI-VAYSSE Loic
>
> Deploying 4 instances of the same app containing a camel-jpa consumer polling on the same database, I noticed that several servers can consume the same entities.
> The polling is currently done as follow :
> # Poll without lock on the `maxResult` first rows
> # On each row :
> ## Apply a lock _select ... for update (NOWAIT)_
> ## Consume entity
> ## Release the lock (commit)
> What can happen with several instances of the consuming on the same database is :
> # {color:green}Server 1 polls the 10 first rows{color}
> # {color:red}Server 2 polls the same 10 first rows{color}
> # {color:green}Server 1 locks row 1 for update and consume it{color}
> # {color:red}Server 2 locks row 1 for update as the previous lock is already released and consumes it{color}
> One fix could be to add a _@IsConsumed_ annotation defining a method to check whether or not the entity has already been consumed. This method would be called at the beginning of the _batchProcess_. That is the work around we applied on our project but directly in our route ie without modifying the component.
> This demand is related to my previous post on the user forum : http://camel.465427.n5.nabble.com/JPA-consumer-component-is-not-handling-multiple-server-concurrent-polling-td5797937.html



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)