Reattaching my patch as a .txt file -- the copy of my message I got back had the patch stripped from it, so I'm not sure it went through to you all.
Jon -----Original Message----- From: Moore, Jonathan [mailto:jonathan_mo...@comcast.com] Sent: Tuesday, July 13, 2010 10:03 AM To: HttpComponents Project Subject: RE: [HttpCache][PATCH] Caching API review (take 2) Ok, I've attached a much simpler patch that only uses the callback in a non-surprising way. Jon -----Original Message----- From: Moore, Jonathan [mailto:jonathan_mo...@comcast.com] Sent: Tuesday, July 13, 2010 9:32 AM To: HttpComponents Project Subject: RE: [HttpCache][PATCH] Caching API review (take 2) I agree that the lack of explicit locking is good; however, I wonder if the interface is now offering something that implementations can't always provide, because not all backing stores will be able to offer this level of transaction. The primary example would be several JVMs in a pool of app servers all sharing the same memcached cache. Memcached can offer an atomic compare-and-swap, but can't offer a generic "perform all these mutations synchronously" as if there was a global lock. As another take, the current implementation (I believe) doesn't actually depend on everything in the current callback to be atomic, and I believe we can rewrite what we have using the existing callback but without doing extra side mutations. Let me take a shot at that and post a patch. Jon -----Original Message----- From: Oleg Kalnichevski [mailto:ol...@apache.org] Sent: Tuesday, July 13, 2010 9:07 AM To: HttpComponents Project Subject: [HttpCache][PATCH] Caching API review (take 2) Jon et al How about a slightly different take? No explicit locking is needed. The callback stays but is made more generic allowing for all kinds of cache mutations, not just variant updates. Can you live with this change? Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
