CODEWITHSUNDEEP
javasynchronizationlockinghazelcast
Keynash
Keynash

Reputation: 350

Can hazelcast IMap be used only for the purpose of locking?

Currently as far as I'm aware, you don't need to use any destroy methods after using IMap#tryLock unlike ILock.

Would it be a good or bad practice to change all ILocks retrieved from HazelcastInstance to IMaps and use code similar to what shown below?

public final T execute(){
    try{
        imapForLocking.tryLock(nonexistentInMapStringKey);
        return executeCodeUnrelatedToMap();
    }finally{
        imapForLocking.unlock(nonexistentInMapStringKey);
    }
}

Upvotes: 1

Views: 2950

Answers (2)

Keynash
Keynash

Reputation: 350

Found my answer here https://groups.google.com/forum/#!topic/hazelcast/9YFGh3xwe8I

It is encouraged by hazelcast developers to use IMap for locking instead of ILock

Yes you have to call destroy as all ILock objects are kept in memory. You can also use a distributed map for your locks:

IMap mapLocks = hazelcastInstance.getMap("mylocks"); mapLocks.lock(theKey);

when you call mapLocks.unlock(theKey), your lock is auto-garbage-collected. This is simpler, faster and cleaner.

Upvotes: 2

noctarius
noctarius

Reputation: 6094

Why do you think you don't need any destroy method?

Probably you should always keep the lock/try/finally/unlock pattern since eventually the lock might need to timeout before being released.

iMap.lock("foo");
try {
    // do something else
} finally {
    iMap.unlock("foo");
}

But actually if you have the feeling you need to lock the map to do some changes you might want to look forward to use EntryProcessor which will run on the key owner and provides you with an implicit lock, so you don't actually need real locking but have the same behavior. Locking itself is always a costly and non preferable operation.

Upvotes: 0

Related Questions