camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Pavlovich <>
Subject Re: [discuss] implementing Locks in Camel
Date Wed, 07 Sep 2011 04:25:31 GMT
Disclaimer-- I haven't used either of these locking technologies described, but understand
how and why Ben is looking to use them.

I think it would be helpful to understand how other use cases would apply to support this
in the DSL.  I can see a lot of ways where users would misinterpret what functionality it
can provide by presuming that it would support locking across all components and endpoint
types.  I think isolating the locking to be as close to the parts of code that need locking
is a good idea-- cuts down on errors due to forgetting to unlock (exceptions, etc).

Another approach might be to create a Bean Processor Support package (aka util library) that
included support for simplifying lock operations via the various methods Ben described.  If
its *only* ever going to be used before and after a processor, what is the benefit to having
it in the DSL, vs leaving it in the user's Java code? 


On Sep 6, 2011, at 3: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