I have several nodes that use JGroups (2.2.7) to communicate w/ eachother. On top of that I use the DistributedLockManager to issue lock-request (two-phased) over all registered nodes.
When a new node registeres on a topic I want the node to be able to find out who holds the lock for a given object. Is there a way to get this information out of the DistributedLockManager?
Thanks in advance,
A correction: It's jg-dev mailing list and not jg-dev forum.
I was looking through the DistributedLockManager source for some other purpose and there seems to be no easy and direct way of getting the info you are asking for.
One possible way out is to make the "owner" object that you pass while acquiring a lock to contain "address" of the node (and any addditional info you want to identify the entity that owns the lock). Note that JGroups DLM does not specify what exactly the "owner" object should contain.
Once you have this, the node that comes up can query any of the existing nodes for the owner information. You need to modify the DistributedLockManager code to get the owner from the "heldLocks" HashMap given its key (the lockId). The heldLock HashMap keeps a mapping of the lockId to the lockDecree, the lockDecree in turn contains "requester" which is nothing but the owner object passed. You need to add an additional method to retrieve this info and pass to the requesting node.
Here is a related problem for which I was looking for a solution from JGroups DLM.
When a member that holds some locks crashes, I want all the locks held by it to get released. Without this support, if a member acquires a lock and crashes before releasing it, no other member will be able to acquire the lock. I feel this is a must feature for any DLM and should have been there in JGroups' DLM implementation. Since JGroups DLM leaves the decision on what the "owner" object should be to the application, the DLM cannot associate the locks to members automatically and hence cannot know what locks to release when a member goes down abruptly.
Another feature that would be nice to have in JGroups DLM is the notion of lock modes (shared and exclusive). Currently, it supports only exclusive mode.
My problem is similar to the one you have. In addition I might have the case where in case of an emergency a hi-prio node needs to be able to take the lock. In that case it has to find out who holds the lock at the moment and release the lock on behalf of that node (it might be off-line). After that it will retrieve the lock itself. For this I also need to know who holds the lock.
Changing the DLM code is an option although I'm not in favour of that. Upgrading to a newer version is more complicated that way. I'll reconsider it though.
One thing I'm looking into at this very moment is to see if I can use JBoss' TreeCache. It runs on top of JGroups and I think I can use it to share my data among several nodes. By choosing the right transaction isolation level I think it is possible to create a locking mechanism (shared or exclusive). If you haven't had a look at JBossCache yet you might be interested in checking it out.
Wrt DLM: I don't think Roman maintains it anymore, maybe Robert Schaffar is taking over. In the meantime; if anyone comes up with patches, e.g. removal of locks held by crashed members, or forced lock removal, then feel free to discuss it (best is on the jg-dev mailing list) and send patches to Robert or me.
Yes, JBoss TreeCache is useful for maintaining cache coherency, and as you said, may be it is possible to use it as a locking mechanism since it supports transactions. I had used it before but just superficially. I will investigate it further and post here a message if I find it useful for locking. Please do leave a message if you happen to find it useful for your locking scenario.
The DLM issue I had raised is actually not an issue. Please check out the discussion happening in the jg-dev forum. We should use distinct/unique ids for each of the DLM instances. With that, node crashes won't be an issue. I had not understood the DLM logic correctly before.
Log in to post a comment.