camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Whytock <>
Subject Re: [discuss] implementing Locks in Camel
Date Tue, 06 Sep 2011 20:29:37 GMT
Just a thought...If you're naming the lock, you should also name the
unlock.  You might want to have multiple locks on a single route, and
you might not want ro release all of them at once.


On Tue, Sep 6, 2011 at 4:16 PM, boday <> wrote:
> hey guys, while working on a solution for a client, I ran into the need to
> "synchronize" multiple routes that modify the same data (users, orders, etc)
> to prevent collisions (stale writes, etc).  Is there an existing way to do
> this that I've overlooked?
> In the past, I've relied on
> AMQ message groups  for JMS based routes and Hazelcast to span
> routes/containers.  I feel this would be a good fit for the Camel DSL.  Has
> anyone looked into this in the past?
> After doing some quick research, it seems like Java
> Lock  seems to be the way to go.  Also, Hazelcast can extend this to be
> distributed across VMs.
> So, I've been playing around with adding distributed locking support with
> Hazelcast (see CAMEL-4397
> ) and wanted to get some feedback on doing this.  In particular, I'm using a
> Lock instance stored in a ThreadLocal variable (to ensure that the same
> thread releases the lock).  Does anyone see any issue with this approach?
> If all goes well with this, I was planning on also adding a DSL API to
> provide a basic support for (non distributed)
> ReentrantLocks .
> something like this...
> from(route1).lock(userId).process(processor1).unlock();
> from(route2).lock(userId).process(processor2).unlock();
> Any advice/comments are welcome...thanks
> -----
> Ben O'Day
> IT Consultant -
> --
> View this message in context:
> Sent from the Camel Development mailing list archive at

View raw message