I got the second one "Ok, *this* time I've remembered to actually attach the patch"
But it's usually easier to find patches again if they are attached to a JIRA. On 13 July 2010 15:20, Moore, Jonathan <jonathan_mo...@comcast.com> wrote: > Ok, can someone else let me know if my patches are showing up? They're > getting stripped from my messages somewhere along the line, and I don't > know whether it's before they hit the list or if my inbound mail server > is stripping them (although I've received Oleg's patches ok). > > Jon > > -----Original Message----- > From: Moore, Jonathan [mailto:jonathan_mo...@comcast.com] > Sent: Tuesday, July 13, 2010 10:16 AM > To: HttpComponents Project > Subject: RE: [HttpCache][PATCH] Caching API review (take 2) > > 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 > > > --------------------------------------------------------------------- > 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
