views:

193

answers:

2

I have a system where some loosely coupled components are communicating by exchanging messages over JMS. I am now looking at a new requirement which leads to some shared resource needing protection from access by two or more components at the same time (more or less an instance of the reader/write problem). I am looking for a way to coordinate access to the shared resource without adding too much additional complexity to the system. (E.g. I wouldn't want to add a dedicated distributed lock manager to the mix if I don't have to).

I have a partial solution in my head which would use the JMS infrastructure as its base. Basically, sending lock-messages to queues. If there is a message in the writers queue, no one may post to that queue until the component that sent the message removes it again. Similarly, when a reader start reading the resource, they would send a message to the readers queue and remove it one they are done. A writer wouldn't start to write until it sees both the readers and the writers queue empty. A reader wouldn't start until it sees an empty writers queue.

Of course, I would need to find a way to synchronize the access to both queues so that a writer doesn't post to the writer queue while a reader posts to the reader queue that already saw the empty writer queue...

Can such a thing be pulled of with a reasonable amount of work? Are there maybe existing implementations of a lock manager on top of JMS? Any papers on the topic you would recommend?

+2  A: 

This sounds very problematic. Too many edge cases. Too many pitfalls.(e.g. what happens if the component crashes and fails to remove the lock?) Don't mess too much with locks, and certainly not with distributed locks. Use the abilities of the JMS server to achieve what you need using transactions and forget about it.

bugspy.net
+1  A: 

No. You may want to check out Hazelcast distributed locks instead.

Hazelcast is an open source (Apache License), transactional, distributed implementation of map, multimap, queue, topic, lock and executor service for Java.

Talip Ozturk