IMap's .get() vs .containsKey()

[su...@suls.org]

Hi,

I've been trying to find out more details/internals about IMap's .containsKey() and how it relates to the .get() function.

How do they compare in terms of runtime performance? 

Is an optimistic .get() followed by an null-check significantly slower compared to a call to .containsKey()?

Why am I asking this: I'd like to keep my hazelcast interactions async - there is .getAsync() but no .containsKeyAsync() equivalent ..

Cheers, Mathias

[Peter Veentjer]

On Mon, Oct 19, 2015 at 4:45 PM, <su...@suls.org> wrote:

Hi,

I've been trying to find out more details/internals about IMap's .containsKey() and how it relates to the .get() function.

How do they compare in terms of runtime performance? 

The are roughly similar. The main difference is that the contains doesn't return the value and therefor is a lot cheaper from a serialization point of view and generated less litter.

 

Is an optimistic .get() followed by an null-check significantly slower compared to a call to .containsKey()?

 

Significant... I don't know.. if you make the key large enough you will notice it.

 

Why am I asking this: I'd like to keep my hazelcast interactions async - there is .getAsync() but no .containsKeyAsync() equivalent ..

It would be an easy feature to add (probably like 10 minutes for the member side).

 

Cheers, Mathias

--
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/8eae2817-5d22-44c1-82f9-dd27f2ddf7f7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ahmet Mircik]

Hi, also you can use this hack instead of method containsKeyAsync : https://gist.github.com/ahmetmircik/7226e9d6da930054226d

​

To view this discussion on the web visit https://groups.google.com/d/msgid/hazelcast/CAGuAWdD7MmQ%3D34rj_W%3DwQyUY1jfY0iTkDTE2ve4xpHM0O0POgw%40mail.gmail.com.

[Wim Deblauwe]

Why does it only work on 3.6 (which is not released) according to the comments  ?

Op dinsdag 27 oktober 2015 15:43:45 UTC+1 schreef Ahmet Mircik:

[Ahmet Mircik]

Because there is no lazy map-entry in previous releases. 

By 3.6, i meant this one :

<dependencies>
    <dependency>
        <groupId>com.hazelcast</groupId>
        <artifactId>hazelcast-all</artifactId>
        <version>3.6-EA</version>
    </dependency>
</dependencies>

To view this discussion on the web visit https://groups.google.com/d/msgid/hazelcast/abcf219a-cee2-4e91-af5e-3776b713f5ca%40googlegroups.com.

[su...@suls.org]

A late thank you to both Peter and Ahmet!

The `submitToKey` approach looks very interesting indeed!

It might have been easier if I properly explained my intentions form the beginning: I am trying to build a cache that will only execute the computation for a value identified by a key once (and only once). Therefore, I can't just use `putIfAbsent` since the V in that method is not lazy. My current solution is based on using a lock for the first access (request 1) and, if locked, register an `EntryListener` for the given key (request 2) so that once request 1 is complete, request 2 can almost immediately complete as well.

Did my words above make any sense at all? 

If so, do you think this is a reasonable approach or am I missing something obvious? And if above didn't make any sense at all - I am happy to try again ;)

Cheers, Mathias