Are Hazelcast's distributed locks automatically & eventually removed from memory

[fruxo]

Hi all,

I'm using distributed locks and, both examining the stats Hazelcast provides via JMX and analyzing the heap-dump, we can see that the number of locks kept in memory is constantly growing.

The way I interact with Hazelcast is pretty simple: given an instance of HazelcastInstance I invoke getLock(lockId) whenever I need a new distributed lock; then the application code uses the lock as it was a typical JDK Lock instance, acquiring it and releasing it in a finally block, that's it.

Now, I've noticed that all these locks are accumulating in memory and does not look like they are getting released. Am I supposed to invoke the "Instance.destroy()" method exposed by the "ILock" interface to achieve this or will Hazelcast eventually infer that the lock can be removed from memory?

Thanks in advance, this is point is pretty crucial for it might be the cause of a memory-leak...

F.

[Talip Ozturk]

> Now, I've noticed that all these locks are accumulating in memory and does
> not look like they are getting released. Am I supposed to invoke the
> "Instance.destroy()" method exposed by the "ILock" interface to achieve this
> or will Hazelcast eventually infer that the lock can be removed from memory?

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.

-talip

[fruxo]

Hi Talip,

thanks for the quick reply! If I moved to IMap, would I be able to replace the ILock.tryLock() with IMap.tryLock()?

Thanks,

F

[Talip Ozturk]

> thanks for the quick reply! If I moved to IMap, would I be able to replace
> the ILock.tryLock() with IMap.tryLock()?

Yes. They behave exactly the same.

-talip

[fruxo]

Thanks a lot!

F

PS: any reason why one should opt for ILocks or IMaps?

[Talip Ozturk]

> PS: any reason why one should opt for ILocks or IMaps?

If you don't have lots of locks and you want to follow the j.u.c.Lock
interface then you can use ILock otherwise IMap is much nicer.

-talip

[fruxo]

Makes sense, thanks!

[jsjunk...@gmail.com]

I am using version 3.3.1 and looking at the implementation of both IMap.lock/unlock (MapProxyImpl) and ILock (LockProxy), both use LockProxySupport for the implementation of locking. So how can it be than when using IMap.unlock() the lock is garbage collected but with ILock.unlock() it isn't?

-JS

[M. Sancar Koyunlu]

It is about garbage-collection of proxies of your data structures. Map and lock proxies are stored in Hazelcast. For lock to cleanup its proxy completely , you need to call ILock.destroy after you finished your work. For locks it is often not clear when you don't need that lock anymore. 

In case of Map.lock. You will have only one proxy and multiple locks over that.

Of course, if you need only one lock and not using that map for anything else, then there is not much gain of using IMap over ILock

--
You received this message because you are subscribed to the Google Groups "Hazelcast" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hazelcast+...@googlegroups.com.
To post to this group, send email to haze...@googlegroups.com.
Visit this group at http://groups.google.com/group/hazelcast.
To view this discussion on the web visit https://groups.google.com/d/msgid/hazelcast/29121714-dc7f-4686-b44e-684014ac136f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.