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 -http://consulting-notes.com
--
View this message in context:
http://camel.465427.n5.nabble.com/discuss-implementing-Locks-in-Camel-tp4775904p4777543.html
Sent from the Camel Development mailing list archive at Nabble.com.
