cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Pötz <reinh...@apache.org>
Subject Re: [c3] Conditional GET
Date Sun, 13 Dec 2009 13:10:38 GMT
Sylvain Wallez wrote:
> Steven Dolg wrote:
>> Sylvain Wallez schrieb:
>>> Reinhard Pötz wrote:

<snip/>

>> This additional layer is used to perform validity checks when
>> necessary and/or desired and not check the validity if not.
>> The intention here is to reuse the abstraction layer and not have this
>> kind of (critical) logic scattered in the individual cache provider
>> adaptors.
> 
> Agree. A cache storage should not have to do much more than get(key),
> put(key, value) and maybe delete(key) and clear().
> 
>> So it is possible to check if a CacheKey is pointing to the same
>> resource *and* if that cached data is still valid - even tho the
>> underlying cache provider has no means of performing the second check
>> (validity).
> 
> I totally agree. Now this doesn't solve the issue: to implement put(key,
> value) on an arbitrary non-java store, I wouldn't trust the CacheKey's
> hashcode() method to produce a uniform distribution that would avoid
> conflicts (same hashcode for different CacheKeys). The solution would be
> to to serialize the CacheKey and either use this as the store key if
> it's not too long, or use a strong hash (e.g. MD5 or FNV) of this
> serialized representation otherwise.
> 
> Mixing key and validity in a single CacheKey object means having several
> store keys (which is different from _cache_ keys in this case) for
> CacheKeys that are equal(), leading to the problems I outlined.

I leave it to Steven to comment on how C3 caching works in detail.

When coming back to my original question about the implementation
conditional get support based on cache keys, the important part of your
comments is that you suggest using a _strong_ hash key. Is there any
concrete implementation that you can recommend? (regarding speed and
potential collisions and of course distributed under some 'friendly'
license)

>>> And BTW, what is the "jmxGroupName" property on CacheKey used for?
>>
>> The jmxGroupName is used for making them accessible via JMX, no?
> 
> Well, I guessed this was somehow related to JMX ;-) Did my homework and
> found its use in cocoon-monitoring's CacheEntrysMonitorInitializer. Nice
> stuff, but I'm wondering if exposing the full key set of a big cache to
> JMX actually scales.

cocoon-monitoring is Dariusz' work, our 2009 GSoC student. I was
thinking about this issue too but decided to keep the code so that
others can improve it .It was my idea that it is probably easier to make
things better than to start them from scratch.

> And there are some cache implementations (again, memcached) that don't
> expose their key set. But since this is mostly used for monitoring
> AFAIU, returning an empty set in these cases should be acceptable.

yes, I think so too.

-- 
Reinhard Pötz                           Managing Director, {Indoqa} GmbH
                         http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member                  reinhard@apache.org
________________________________________________________________________

Mime
View raw message