On Fri, Jul 22, 2011 at 10:38 AM, Abhishek Sanoujam <asanou...@terracottatech.com> wrote:
> InvalidateOnChange has got some other implications too. > When true, reads/puts on the map are done without locking. Which means if > some other node has updated the value, it might still read old data. > This doesn't seem to be a problem with your usage as you have full control > over data partitioning and you are making sure only one node is going to > update. (as a side note, with invalidateOnChange=true, when some other node > updates, an invalidation comes eventually from the L2 which removes the > entry from the local cache and next time a get for that key goes to the L2 > to fetch updated values). This is eventual consistency. Got it, even if I must confess the invalidateOnChange true/false meaning is somewhat misleading: I mean, I was expecting to get incoherent writes/reads with invalidateOnChange=false, rather than the other way around ... but that doesn't really matter :) Also, I can live with the current default setting too, because I'm actually forced to invalidate all caches on topology changes, so I would only generate some extra calls this way ... the real game changer would be an API to clear only a given entry :) > With false, reads/puts are all done under clustered locks. So every read/put > will take locks (and acquiring write locks makes other L1's remove the > corresponding key from its local cache). > Don't see a problem why setting it to true would be a problem for you. > But then, clearing all local cache can have implications too. You may not > get monotonic reads. Like if a thread does a remove, and you clear the local > cache, next get may read the value from the L2 and the remove might still be > in wire returning the old value instead of null. > But it might not be a problem for you, like if you block all access to the > map while you are rehashing/redistributing. Yep, that's not a problem. > However, there's one method in CDSMDso, evictedInServer(boolean > notifyEvicted, Object key) which actually does a remove from a local cache > for a particular key. But you'll have to do some magic to grab that CDSMDso > segment for that particular key. Using that method with notifyEvicted=false > will actually remove from the local cache. I have a concurrency level of 1, so I only have one segment, but is there any public method to access it? Thanks! Sergio B. -- Sergio Bossa http://www.linkedin.com/in/sergiob _______________________________________________ tc-dev mailing list tc-dev@lists.terracotta.org http://lists.terracotta.org/mailman/listinfo/tc-dev