Inlined... Cheers, Abhishek
On 7/22/11 1:20 PM, Sergio Bossa wrote: > On Fri, Jul 22, 2011 at 8:58 AM, Abhishek Sanoujam > <asanou...@terracottatech.com> wrote: > >> That method will definitely clear the local cache of the map, but its got >> some gotchas. Like when using strong consistency (or >> invalidateOnChange=false at the CDSM level), it will also broadcast all >> other nodes to clear its local cache. For eventual consistency >> (invalidateOnChange=true), it will clear the local cache of that node only. > I definitely don't want to clear the local cache on all nodes: given > it seems that invalidateOnChange=false by default, I should set it to > true, right? > 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. 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. >> Looks like you are using custom-dso mode, as that class isn't really exposed >> from toolkit for express (though I think you can still use it). > Nope, I'm using express mode with some little hacks partly contributed > by Alex :) > BTW, the code is open source: > http://code.google.com/p/terrastore/source/browse/src/main/java/terrastore/internal/tc/TCMaster.java > >> Can you explain your use case a bit more, why the need to clear the local >> cache explicitly. > Sure: basically, I want full control over data locality, so that I can > optimize memory usage and always do local reads. > Let me explain those two points a little bit: I use a consistent > hashing routing algorithm to partition data between L1s, in order to > minimize L1/L2 communication, and I want every L1 to only hold the > data it is responsible of given the routing algorithm; in order to do > so, everytime an L1 joins/leaves the cluster, I manually flush local > entries so that: > 1) Data partitioning will change, so I want to flush entries which > will "migrate" to other L1s; this way, memory usage is optimized. > 2) Also, given I have complete control over data partitioning and > routing, I can always do unsafe (unlocked) local reads because either: > a) the value is there, and it is the up-to-date value because I can > only read/write it from that node (and if another node joins, it will > be *flushed*) b) the value is not there, which means it is the first > time I access it, so it must be loaded from L2. > > Obviously, I don't want to clear *all* local caches, and it would be > great if I could clear only selected entries (that is in my case, > those entries whose routing destination changed). Right now, there's no supported way to remove/clear particular keys from the local cache. CDSM.localKeySet() might help you a bit, it will return you the set of keys present locally, but i don't really have anything on top of my head that you can use to clear those particular keys. 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. >> You can rely on the consistency modes (strong or eventual) >> (and in case of CDSM, invalidateOnChange=true/false) on when the local cache >> gets invalidated. Trying to see if there is some feature request that can >> come out of it. The consistency modes right now does all the hard work to >> keep the cache consistent with the desired consistency, and messing it up >> may give unexplained behaviors with expected consistency guarantees. > Got it, but as you may see I have other requirements: do you see any > specific problems with my usage of the "clearLocalCache" method? > > Thanks! > > Sergio B. > _______________________________________________ tc-dev mailing list tc-dev@lists.terracotta.org http://lists.terracotta.org/mailman/listinfo/tc-dev
