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.
