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.
richie
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-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
