[
https://issues.apache.org/jira/browse/CAMEL-4397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben O'Day updated CAMEL-4397:
-----------------------------
Attachment: CAMEL-4397.patch
Attached is a rough patch that I'd like some feedback on. In particular, the
use of a static ThreadLocal variable in the Producer to store/retrieve the
reference to java.util.concurrent.locks.Lock. This seems to work (in my simple
tests), but I have my doubts about how this will stand up in the more complex
routes/containers (OSGi, etc).
Is there an alternate approach that I should be using to ensure that the unlock
is called from same thread that created the Lock? thanks...
> add route support for Hazelcast distributed locking/unlocking
> -------------------------------------------------------------
>
> Key: CAMEL-4397
> URL: https://issues.apache.org/jira/browse/CAMEL-4397
> Project: Camel
> Issue Type: Improvement
> Components: camel-hazelcast
> Reporter: Ben O'Day
> Assignee: Ben O'Day
> Priority: Minor
> Fix For: 2.9.0
>
> Attachments: CAMEL-4397.patch
>
>
> add support for Hazelcast distributed locking/unlocking APIs in a route...see
> http://www.hazelcast.com/documentation.jsp#Lock
> something like this...
> {code}
> from("direct:processLocked")
> .doTry()
> .toF("hazelcast:%s%s", HazelcastConstants.LOCK_PREFIX,
> simple("${header.id}"))
> .bean(MyProcess.class)
> .doFinally()
> .toF("hazelcast:%s%s", HazelcastConstants.UNLOCK_PREFIX,
> simple("${header.id}"));
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
