[
https://issues.apache.org/activemq/browse/CAMEL-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=52090#action_52090
]
Andi Abes commented on CAMEL-1650:
----------------------------------
Sounds that what you're looking for is a bit like transaction management - you
want to make sure that the Quartz event gets processed exactly once.
If the UnitOfWork provided a means to register "start" synchronization
objects, with access to the Exchange then you could potentially do something
like:
- sync.start() - extract the message ID and perform duplication check against
DB (or memory) and implement your decision algorithm, potentially delaying
until timeout. Potentially polling for completion against the DB. In a memory
based approach, you could get notified when the lock on the process is signaled.
-sync.onFailure / onComplete would update the database (memory) with the
status and continue.
this basically would provide a means to have an "exclusive" unit of work...
> Race condition in IdempotentConsumer
> ------------------------------------
>
> Key: CAMEL-1650
> URL: https://issues.apache.org/activemq/browse/CAMEL-1650
> Project: Apache Camel
> Issue Type: Bug
> Components: camel-core
> Affects Versions: 2.0-M1
> Reporter: Oliver Hecker
> Fix For: 2.1.0
>
> Attachments: IdempotentConsumerTest.java
>
>
> A possible possible race condition exists in the IdempotentConsumer
> implementation:
> The code first checks in the MessageIdRepository if the message was already
> processed. If not then it processes the message and
> afterwards adds the id to the repository. (See also
> http://issues.apache.org/activemq/browse/CAMEL-1451). There is no locking
> between the check with "contains" and the insert with "add". So if multiple
> threads/instances try this in parallel for the same id, then
> it might happen that more than one finds the id not yet contained in the
> repository and the same message is processed multiple
> times.
> I enclose an extended version of IdempotentConsumerTest which illustrates the
> problem.
> It is important to note that even if the test demonstrates the issue with an
> MemoryIdempotentRepository a solution should also
> address the case of a database based respository in a clustered environment.
> So this might imply that some locking mechanism on the
> database is required.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
