hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Campbell, Joseph" <Joseph_Campb...@Comcast.com>
Subject RE: [HttpCache][PATCH] Caching API review (take 2)
Date Tue, 13 Jul 2010 14:26:01 GMT
FYI - Jon, I got your Atomic patch as a .txt file no problem.

Joe

--
"Strength of numbers is the delight of the timid. The Valiant in spirit
glory in fighting alone." 
     Mahatma Gandhi

Joe Campbell | one comcast center | philadelphia, pa 19103 |
215.286.5073



-----Original Message-----
From: Moore, Jonathan [mailto:Jonathan_Moore@Comcast.com] 
Sent: Tuesday, July 13, 2010 10:21 AM
To: HttpComponents Project
Subject: RE: [HttpCache][PATCH] Caching API review (take 2)

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_Moore@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_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


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


Mime
View raw message