cache-value limit + default value.

[Peter Veentjer]

Hi Guys,

with the 'cache-value' setting on the map, the value can be cached. I
have 2 questions:


question1:

I guess there is a limit on the number of cached values, otherwise you
can run into Out Of Memory Exceptions.

What is the limit, and how can it be configured?

question 2:

By default this value is set to true; which surprises me because it
has a lot of implications. E.g. the following code is completely
broken:

class Employee implements Serializable{
boolean fired = false
}

Employee e = employeeMap.get("123");
e.fired=true;
employeeMap.put("123",e);

The big problem is that 'e' is now a shared instance since values of
the map by default are cached. So if there are 2 threads on the same
machine that both want to access entry "123", they
will be getting back the same instance and therefor they will make
modifications on the same fields. Which not only can cause race
problems, it also can cause jmm problems. Since the stuff
eventually written to the map could be an interleaving of multiple
updates. So apart from this code potentially suffering from a lost
update, it also can be suffering from extremely nasty low level
concurrency issues.

Wouldn't it make more sense to make 'cache-value' by default false to
prevent 99% of the users to run into this issue?

Peter

[Peter Veentjer]

Does the 'cache-value' reflect on the near cache?

So if I configure a map to use the near cache, and I disable
'cache-value', could it be that
subsequent calls to the map of an entry that is not owned by that
member (so it needs to come
from the near cache) do return the same instance?

Or when I disable 'cache-value' than no matter what I configure
otherwise I'll get the guarantee
that I will always get a newly created value?

[Mehmet Dogan]

question1:

I guess there is a limit on the number of cached values, otherwise you
can run into Out Of Memory Exceptions.

What is the limit, and how can it be configured?

There is no limit, value is cached per entry.

 

question 2:

By default this value is set to true; which surprises me because it
has a lot of implications. E.g. the following code is completely
broken:

class Employee implements Serializable{
   boolean fired = false
}

Employee e = employeeMap.get("123");
e.fired=true;
employeeMap.put("123",e);

Hazelcast does not have any purpose to make non-thread-safe objects thread-safe. When Employee object above is put into / get from a JDK ConcurrentHashMap, there will be same race conditions / jmm issues. Users should use sync-blocks, locks, CAS (using map.replace ) etc. to avoid concurrency issues.

 

Wouldn't it make more sense to make 'cache-value' by default false to
prevent 99% of the users to run into this issue?

Yes, disabling value cache makes more sense to me.

[Mehmet Dogan]

Near-cache stores serialized (binary) forms of values owned by other members. 'cache-value' is valid only for locally owned entries. So, near-cache does not return the same value for subsequent calls. 

If 'cache-value' is disabled then all returned objects will be newly created (deserialized from binary each time). 

@mmdogan

--
You received this message because you are subscribed to the Google Groups "Hazelcast" group.
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.