hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richie Jefts <rje...@rfcode.com>
Subject Re: [HttpCache][PATCH] Caching API review
Date Mon, 12 Jul 2010 16:36:50 GMT
I dislike getLock(). It exposes implementation details. Why not keep the 
old style of code and make it more explicit it may modify multiple 
entries. Something like.

BasicHttpCache.update(String url, HttpCacheUpdate update);

It ensures callers don't have to mess with the lock since it all happens 
behind the scenes for them. Plus it allows the locking of BasicHttpCache 
to change if necessary without callers having to deal with the change.


On 07/12/2010 11:02 AM, Oleg Kalnichevski wrote:
> Jon et al
> I started looking at the Caching API more closely primarily to find out
> how difficult / feasible it should be to put together alternative cache
> backends such as echache or file system based. I stumbled upon a few
> minor issues I thought I should discuss with you.
> (1) HttpCacheUpdateCallback
> I think I understand the rationale behind the interface but kind of
> dislike the fact that its implementations often manipulate the cache
> behind the scene in non-obvious ways. One call to #updateCacheEntry may
> result in mutation of multiple entries and multiple invocations of
> #putEntry methods. Do we need #updateCacheEntry at all? What we need is
> ability to update the cache while ensuring the consistency of its
> content. Why not just use an exclusive lock to execute multiple cache
> operations as a unit of work?
> Please take a look at the patch attached and let me know if you can live
> with the proposed changes?
> (2) Do we really need HttpCacheEntrySerializer? It does not appear to be
> used anywhere but in tests.
> Oleg

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

View raw message