I don't know, the whole thing looks very error prone to me. Looking at
your example, I can see a million ways in which the hazelcast header
could disappear, which would totally mess up the locking (ok, making it
a property would help a bit).
For the technology being used I can see others working equally well,
zookeeper for instance, so it almost looks like what you need there is
not just an id, but a uri that identifies the component providing the
lock and the id of the lock.
That said, again, as far as distributed technologies, things could go
wrong in so many ways, it's not even funny. Life is very creative. It
kinda looks like a recovery mechanism is needed too. Not sure about the
DSL either, I don't think I'd like to see this in the DSL.
I'd like us to spend a bit of time on this and come up with a solid
solution.
Coming back to the original problem, the solution I see is to wrap your
logic that access the data in a web service (or one route) and access it
from other routes. Would that work?
My $0.02,
Hadrian
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.
