CacheLoader problem (null enties in cache)

[tomislav]

Caches with loader will create cache entries with a null value (when loader returns null on load(key)).

1. cache without loader

cache.exist(key1) -> false

cache.get(key1) -> null

cache.exist(key1) -> false

cache.keys() -> []

2. cache with loader

cache.exist(key1) -> false

cache.get(key1) -> null (loader : load(key1) returns null)

cache.exist(key1) -> true

cache.keys() -> [ key1 ]

[Tim Peierls]

Another item for the CommonGotchas page.

--
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/-/b1J0RmRlYjFzVHdK.
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.

[Timothy Peierls]

But it could be addressed by giving MapLoader.load(key) a way to signal that no value was found, perhaps by throwing NoSuchElementException. The IMap implementation would have to store a NO_VALUE sentinel value (to be distinguishable from null) in that case.

MapLoader.loadAll(keys) wouldn't need an exception thrown; it could return the entries for the keys that have values in the backing store. The IMap implementation would have to store the NO_VALUE sentinel for every key in the difference between the given key set and the keySet of the map returned by loadAll.

Null values in Maps of any flavor are almost always a Bad Thing.

--tim

[tomislav]

I think  this  is a genuine bug. It should be possible to check existence of entry before reading it (e.g. containsKey() ). If entity does not exist, there is no need to have entry to point to its non-existence.

Hypothetically even if there is a need for (key, null), behavior should be the same for map with or without loader.

[Tim Peierls]

IMaps don't adhere to the standard Map/ConcurrentMap contract, so it's not exactly a bug. And many uses of containsKey are suspect, e.g., 

if (map.containsKey(key)) {

    Value value = map.get(key);

    ...

}

should usually be:

Value value = map.get(key);

if (value != null) {

    ...

}

But it is kind of annoying, and since it would be (I believe) fairly easy to make it adhere more closely in this case, I think it's worth opening an issue.

--tim

On Thu, Jun 2, 2011 at 12:36 PM, tomislav <jomo...@gmail.com> wrote:

I think  this  is a genuine bug. It should be possible to check existence of entry before reading it (e.g. containsKey() ). If entity does not exist, there is no need to have entry to point to its non-existence.

Hypothetically even if there is a need for (key, null), behavior should be the same for map with or without loader.

--

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/-/TUk5WDAyaXprUm9K.

[Fuad Malikov]

Yes this is a bug, and an issue should be created. Cache with loader shouldn't change the result of

map.containsKeyt(key1)  and map.keySet().

Fuad

--
Fuad Malikov
Managing Partner, Hazelcast
http://www.hazelcast.com
+90.538.378.9777
http://www.linkedin.com/in/malikov
http://twitter.com/fuadm

[Timothy Peierls]

On Friday, June 3, 2011 3:50:22 AM UTC-4, fuad wrote:

Yes this is a bug, and an issue should be created. Cache with loader shouldn't change the result of

map.containsKeyt(key1)  and map.keySet().

Issue 578:

http://code.google.com/p/hazelcast/issues/detail?id=578

--tim