camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Willem Jiang <>
Subject Re: [discuss] implementing Locks in Camel
Date Wed, 07 Sep 2011 07:54:49 GMT
Maybe a lock block DSL with a key could help use to implement such a 


On Wed Sep  7 15:07:33 2011, boday wrote:
> thanks for the feedback.  I agree that this needs more consideration and may
> not even be a good fit for Camel (hence this post).  I do feel like this is
> becoming a more common use case given the trend towards more
> concurrent/distributed solutions (clustering, cloud deployments, big data,
> etc).  AMQ groups, database locking only gets you so far...
> That being said, my take is that we should be able to do the following in a
> declarative way.
> Lock lock =<SomeLockImpl>.getLock(myLockedObject);
> lock.lock();
> try {
>      // do something that requires single-threaded access to
> myLockedObject...
> } finally {
>      lock.unlock();
> }
> I was originally thinking it was a good fit for Camel DSL (similar to
> marking a route as transacted), but perhaps beans, processors, interceptors,
> strategies, policies or annotations are a better fit...
> Anyways, I started playing around a simple lock(<expr>) DSL API tonight that
> simply wraps a child processor (similar to loop()).  This seems like a
> feasible approach to add basic read/write locking on a given object for a
> single synchronous processor.  But, this gets complicated fast when you
> start thinking about multiple locked objects in a route, nested routes,
> async processing, etc.
> Anyways, I'll play around with it a little more and see where it goes...
> Matt Pavlovich wrote:
>> 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?
>> Matt
> -----
> Ben O'Day
> IT Consultant -
> --
> View this message in context:
> Sent from the Camel Development mailing list archive at

View raw message