IMap.lock() behaviour for non-existent keys?

[kjko...@gmail.com]

Dear All,

I have a distributed hazelcast map. At run-time I remove entries from that map that have no functional value any longer. However, when I subsequently lock a non-existent map entry, the locking thread seems to hang.

What is the expected behaviour for locking non-existent keys on an IMap?

What is the expected behaviour for locking removed entries on an IMap?

I have to resort to this idiom:

if (map.containsKey(key)) {

   map.lock(key);

   criticalSection(...);

} else {

   edgeCaseCode(...);

}

Unfortunately, this leaves a gap between map.containsKey() and map.lock() for another thread to remove the key from the map, causing the lock() to hang.

On top of that, this causes Hazelcast to go onto the network twice: once for the containsKey() operation and once for the map lock.

It would be nice if lock() would throw an exception if the key is not in the map.

Kees Jan

[Mehmet Dogan]

Map.lock() should work without an existing value/mapping. Otherwise it's a bug. Can you send a test case to reproduce the issue?

@mmdogan

~Sent from mobile

--
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.
For more options, visit https://groups.google.com/groups/opt_out.

[kjko...@gmail.com]

Dear Mehmet,

Thank you for responding. Can you please tell me what "should work" means? What is the expected behaviour for non-existent items on a map?

Kees Jan

[Mehmet Dogan]

No matter key has a value or not, key exists or not, Map.lock() should work. Locks should not depend on values.

Which version are you using? And can you write a test to reproduce the issue?

@mmdogan

~Sent from mobile

[kjko...@gmail.com]

Dear Mehmet,

I'd love to write a test case, but I don't know what to test for as I don't understand the expected behaviour of map.lock() for non-existent keys. :)

From your responses I gather that when I lock a key on a map, I should get a lock no matter whether the value is present in the map or not. Other threads (possibly on other systems) would block on their invoke of map.lock() until the non-existent key is unlocked. Correct?

If I lock a non-existent key, what happens if the key is introduced during the lock's presence? Would subsequent calls to lock() block until unlock, or is the new item on the map considered different from the present lock?

Assuming the key is present in the map, does the locking have any effect on get() and put() operations on the same key on the same map?

Kees Jan

[kjko...@gmail.com]

Oh, and I use 3.1.1.

[Ali Gürbüz]

What mehmet said is either there is a value or not it is irrelevant for locking.

You lock the key.

answers inlined 

On 20 Nov 2013, at 14:15, kjko...@gmail.com wrote:

Dear Mehmet,

I'd love to write a test case, but I don't know what to test for as I don't understand the expected behaviour of map.lock() for non-existent keys. :)

From your responses I gather that when I lock a key on a map, I should get a lock no matter whether the value is present in the map or not. Other threads (possibly on other systems) would block on their invoke of map.lock() until the non-existent key is unlocked. Correct?

correct

If I lock a non-existent key, what happens if the key is introduced during the lock's presence? Would subsequent calls to lock() block until unlock, or is the new item on the map considered different from the present lock?

If key introduced ( put(key, value); ) during lock’s presence; firstly if the locker thread is the introducer then value be putted to map and key is still locked.

secondly another thread is the introducer then it will wait until the key unlocked.

This is same for subsequent lock calls, they will block if from another thread. if locker tries to lock again then it will be locked twice so should be unlocked twice.

Assuming the key is present in the map, does the locking have any effect on get() and put() operations on the same key on the same map?

locking does not have any effect on get but put will block if from another thread.

[kjko...@gmail.com]

Dear Mehmet and Gurbuz,

I since moved to an implementation where keys are no longer deleted from the map. Making a simple test case revealed nothing, so I suspect this was a problem with my code and not Hazelcast.

I created a quick patch for the imap javadoc to clarify the behaviour https://github.com/hazelcast/hazelcast/issues/1200 Hopefully it helps someone in the future.

Kees Jan