Map Lock vs Distributed Lock

[Iso]

Hi,
I have a question about the locks in Hazelcast. e.g. MapLock vs Distributed Lock

where's the difference? is there any difference in term of performance ?

for example:

1.
...
Config config = new Config();
HazelcastInstance instance = Hazelcast.newInstance(config);

map.tryLock("test", 1000, TimeUnit.MILLISECONDS);
    //do something with map
map.unlock("test");


or:
2.
maplock = instance.getLock("testLock");

try {
   if(maplock.tryLock(1000, TimeUnit.MILLISECONDS)){
     try {
         //do something with map
           } finally {
             maplock.unlock();
           }
        }
    } catch (InterruptedException e) {
        // TODO Auto-generated catch block
        e.printStackTrace();
    }


where is the significant difference ?
in //do somethign with map
there's only map operation no other operations will be executed

please help :)

thank u

[Mustafa Sancar Koyunlu]

Hi,

There is no notable performance difference.

For details, you can take a look at here:

http://blog.codepoly.com/hazelcast-tip-use-imaplock-or-ilocklock

--
You received this message because you are subscribed to the Google Groups "Hazelcast" group.
To view this discussion on the web visit https://groups.google.com/d/msg/hazelcast/-/d3cJRG8IziEJ.
To post to this group, send email to haze...@googlegroups.com.
To unsubscribe from this group, send email to hazelcast+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/hazelcast?hl=en.

[Iso]

Hi,

Thanks for reply.
In my situation I need a lock once when a hazelcast Instance goes online. New Instance should write some data into a distributed Map.
The Lock is here to prevent problems if 2 Instances goes online at the same Time (can occur in contex of my project but very seldom), I have no control over the number and starting time of instances.

 That means for me that I can't destroy the Lock, since I dont know when or if an other Instance will go online.
So is a map.lock better in this situation, right ?

Thannks again

Iso

[enes akar]

Yes map.lock seems better for your scenario.

--

You received this message because you are subscribed to the Google Groups "Hazelcast" group.

To view this discussion on the web visit https://groups.google.com/d/msg/hazelcast/-/wqCf8g36FoYJ.

To post to this group, send email to haze...@googlegroups.com.
To unsubscribe from this group, send email to hazelcast+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/hazelcast?hl=en.

--
Enes Akar
http://www.linkedin.com/in/enesakar

[Iso]

Thank you for help.

[d...@flamingoshore.com]

From the documentation:

ILock-based locks use system resources even when they are not acquired. You have to call destroy(), but this can have a side effect when another thread is trying to acquire it. ILock-based lock is a good choice when you have a limited number of locks. The IMap-based locks are auto-destructed. They use no resources when they are not acquired. This implies they are invisible for monitoring unless they are being hold by some thread.

If you are just