hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Moore, Jonathan" <Jonathan_Mo...@Comcast.com>
Subject RE: [HttpCache][PATCH] Caching API review (take 2)
Date Wed, 14 Jul 2010 16:22:40 GMT
Hi Oleg,

Looks good to me, thanks.

Jon

-----Original Message-----
From: Oleg Kalnichevski [mailto:olegk@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_Moore@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_Moore@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:olegk@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-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message