On a note of CacheService#setMap( ConcurrentMap<K, Pointer<V>> map ), you wouldnt want to drop this, as then you would leave buffered data off the heap with loosing critical information to where it is, thus causing a possible memory leak, unless on doing this, you free'd all the buffers.
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. 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/ >
