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. +1 -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sun, Feb 26, 2012 at 1:51 AM, Michael André Pearce <[email protected]> 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 >>> >>> http://people.apache.org/~simonetripodi/ >>> http://simonetripodi.livejournal.com/ >>> http://twitter.com/simonetripodi >>> http://www.99soft.org/ >> >
