incubator-directmemory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <>
Subject Re: changing the DM behavior at runtime
Date Sun, 26 Feb 2012 01:11:37 GMT
Hi Mike,

> I dont see any scenario  of resetting the map after youve set it the once (correct me
if you can think of one), surely this is where then maybe set method should be removed and
it is passed in at construction, and the field is final? avoiding risk of changing it ever.

that is exactly what I meant, I don't see any scenario as well - but
ATM users are still exposed to the risk of damaging the application.
the ConcurrentMap ATM is totally replaced without any check.



On Sun, Feb 26, 2012 at 1:51 AM, Michael André Pearce
<> wrote:

> Mike
> On 26 Feb 2012, at 00:33, Michael André Pearce wrote:
>> Also can i suggest locking on the key for put/updates/deletes? avoids someone getting
a key whilst it is in transitive state of being updated by another, ive seen before a fancy
way of doing this, avoiding a lock for every key, will have to try remember.
>> On 26 Feb 2012, at 00:24, Simone Tripodi wrote:
>>> Hi all guys,
>>> I had a chat with Benoit in another thread and I realized no one of
>>> our class is Thread safe - what do you think of actual behavior that
>>> every component accepts a setter for any member - that could cause
>>> strange behaviors at runtime?
>>> I would analyze wich components can be converted to immutable - IIUC
>>> Benoit agreed with me on having some PointerImpl members as immutable,
>>> i.e. CacheService#setMap( ConcurrentMap<K, Pointer<V>> map ) means
>>> dropping all the already stored data :)
>>> Thoughts?
>>> best,
>>> -Simo

View raw message