Yeah, we have a DelegateProcessor for before/after processing.
Hadrian
On 09/07/2011 12:25 AM, 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
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 http://activemq.apache.org/message-groups.html
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
http://download.oracle.com/javase/6/docs/api/java/util/concurrent/locks/Lock.html
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 https://issues.apache.org/jira/browse/CAMEL-4397 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)
http://download.oracle.com/javase/6/docs/api/java/util/concurrent/locks/ReentrantLock.html
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 -http://consulting-notes.com
--
View this message in context:
http://camel.465427.n5.nabble.com/discuss-implementing-Locks-in-Camel-tp4775904p4775904.html
Sent from the Camel Development mailing list archive at Nabble.com.
