Hi Oleg, Looks good to me, thanks.
Jon -----Original Message----- From: Oleg Kalnichevski [mailto:ol...@apache.org] Sent: Tuesday, July 13, 2010 4:19 PM To: HttpComponents Project Cc: Moore, Jonathan Subject: RE: [HttpCache][PATCH] Caching API review (take 2) I checked the patch in with some minor tweaks. As long as HttpCache is expected to be able to update just one entry as an atomic unit of work I am fine with the API as is. Please review. Oleg ... > -----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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
