Just a thought...If you're naming the lock, you should also name the unlock. You might want to have multiple locks on a single route, and you might not want ro release all of them at once.
Don On Tue, Sep 6, 2011 at 4:16 PM, boday <ben.o...@initekconsulting.com> 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. >
