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 Tue, 13 Jul 2010 14:03:00 GMT
Ok, I've attached a much simpler patch that only uses the callback in a
non-surprising way.


-----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.


-----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?


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

View raw message