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

Reply via email to